After a couple of decades of fighting over technology turf, manufacturing and corporate IT groups still struggle over certain decisions. However, the merger of operations and information technologies in light of the industry’s push toward Big Data, remote access, cloud computing and even Internet of Things initiatives has been bringing the two groups together more than ever before.
One area where the best practices of IT are infiltrating OT (operations technology) for the better is in the approach toward building enterprise-wide automation architectures.
During Inductive Automation’s 2014 customer conference, Travis Cox, director of training at Inductive Automation shared a number of best practices for building an enterprise architecture for OT. Granted, his presentation focused on how to do this using Inductive Automation’s Ignition product, but many of his points were widely applicable to smart enterprise architecture building regardless of whose systems you may be using.
The essence of his presentation dealt with smartly managing the amount of servers, projects and templates you need to operate efficiently.
The first step in determining how many servers you need is to know your data requirements. To determine this, Cox said, you need to know:
* How many PLCs you are using;
* What kinds of PLCs they are;
* Which protocols the PLCs use;
* How many tags you have (and how many are associated with each PLC);
* How many historical tags you have;
* How quickly your system needs to process real time tag values;
* Which tags need to be read constantly;
* How many alarms you have;
* How fast you need to log historical data; and
* How long do you need to keep historical data.
Cox said that, in his experience, when asking manufacturers these questions, the typical answers he gets are: We have 100,000 tags, 25 different PLCs, and we want real time and historical data collected at a 10 second rate.
The problem is that “no SCADA software can do that,” Cox said. To step back and approach the process more realistically, you should: Keep in mind that I/Os will typically be the bottleneck to your data collection; know your PLC limit; and ask yourself how fast can your PLCs get all the data you need.
Cox says that a more realistic answer is to have:
* 75,000 real-time tags, with 50,000 being on-demand (leased at a 10 second rate), 15,000 captured at a 10 second rate; 5,000 captured at a 30 second rate, 4,000 at a one minute rate, and 1,000 at a one second rate;
* 25,000 historical tags with 5,000 captured at a one second rate, 5,000 at a 10 second rate, 10,000 at a 30 second rate, and 5,000 at a one minute rate; and
* 25 different PLCs.
Once you’ve determined your realistic data collection needs, Cox says the following best practices are the next step you should take in building your enterprise automation system architecture:
* Put leased scan class tags into a separate PLC connection than the one that holds your constant tags;
* Expression and query tags should be placed into separate scan classes;
* Stagger scan classes (e.g., 5 sec, 5.5 sec, 6 sec) to spread out the load;
* Use multiple I/O servers when you can’t read all your tags from a single machine.
* Use multiple I/O servers to distribute the device communication load in large tag systems.
* Separate you database from app server. “Keeping both on the same server means that your system is not scalable because databases require more resources,” Cox said. “The more space you give databases on a server, the better their performance.” Plus, by having databases on a dedicated server, IT can do maintenance on this server and not affect production apps like Ignition. Cox recommends that a database server have multiple cores, 8 GB+ memory, 1 TB+ hard disk space, and RAID 1+0.
