Control systems integration for full automation

Data collection and data analytics are the foundation of continuous improvement, but implementing a process to collect and analyze data on existing equipment rarely offers the return on investment to survive the budgeting process as a standalone project. A solution is to build the foundation for data collection and analytical capabilities into a project up-front. A small investment in the correct network infrastructure, programmable logic controller (PLC), or supervisory control and data acquisition (SCADA) systems can have a tremendous impact on operations without breaking budgets.

For a good illustration of the process necessary for realizing a data collection and data analytics solution, consider the process put in place for a standalone production cell that expertly performs specific tasks while conforming to AMS-2750E, a national data collection and integrity specification for the aerospace industry. If you replace this industry specification with any other requirement from a governing body (i.e., FDA, USDA, EPA, or DEC), the process of integrating those requirements into your process will remain the same.

The purpose of this production cell is to heat parts for a particular time to a specific temperature in an atmosphere where the level of carbon also is controlled. By adding hydrocarbon-based liquids and gases into the 2000 deg F furnace, carbon can be driven or removed from the parts while simultaneously changing the structure of the material to make it stronger. Even more crucial than the heating is the cooling of the part in a fixture to help it maintain the intended shape. Because of the use of a robot, as well as the introduction of flammable liquids and gases into a 2,000F furnace, there were safety standards to meet as well as process control and quality criteria to uphold. To manage these requirements, the following automation components were selected:

• Honeywell Flame Safety Relay
• Allen Bradley Guard Logix Safety platform
• PanelView Plus V6 operator interface
• FANUC R2000iB/210F six-axis robot
• Inductive Automation Ignition SCADA

All manufacturing processes have one thing in common: field-mounted sensors and instruments that tell us how a process is performing. It does not matter whether these components are connected to an automation platform or have local displays for an operator to manually record data into a log book. The first step in collecting data is to concentrate the data into one location, or in this case, clusters of instruments in multiple locations.

A programmable logic controller (PLC) from Allen Bradley provided a one-stop-shop for data collection, as well as process control. Data from the instruments and sensors was brought to the safety PLC using standard wiring methods, 4-20 ma analog signals, and discrete digital signals. Input/Output(IO) devices were concentrated on different pieces of equipment within the cell. In addition, the cell needed to easily break down for shipping, leading to the use of Allen Bradley’s Point IO. The Point IO panels were placed on various pieces of equipment in the cells where the instruments for that piece of equipment were wired. In addition to the instruments, numerous variable frequency drives needed to be controlled. In this case, a different approach was taken by controlling and monitoring these drives over a network connection instead of discreetly wiring them.

To network the Point IO panels and variable frequency drives (VFD) back to the safety PLC, an Ethernet ring topology was chosen to allow each device two communication paths back to the safety PLC, creating network redundancy. Two Ethernet cables were run to each Point IO block and VFD to support both safety IO, as well as standard process control IO. This reduced the amount of field wiring that needed to be performed when the cell arrived at the client’s site for final installation as the local device wiring for each component in the cell was left intact for shipping. Only the network cables and power for each piece of equipment needed to be run by the local electrician.

To collect data from the FANUC robot, a similar approach was chosen as the VFD and used an Ethernet connection talking the Ethernet IP protocol between the robot controller and safety PLC. By using an industry standard cabling solution like Ethernet and talking a standard industrial protocol over that cable like Ethernet IP, vast amounts of performance and diagnostic data could be collected about the robot and VFDs. An additional benefit was the precision of commands to these devices through using a networked solution verses a traditional wiring approach. The process and diagnostic data were seamlessly presented to the operator through the PanelView Plus graphical interface, which performed and felt like an integrated cell even though there were multiple controllers and devices in the cell from various manufacturers.

A choice had to be made for this internal network for the point IO, robot, and VFD communications: Ethernet or ControlNet. Given that both network solutions supported the required safety features, the decision fell to cost and component integration. Ethernet components, such as cabling, termination devices, and network appliances like switches, are numerous, making the Ethernet versions more cost effective than the ControlNet equivalent. The decision to use Ethernet was further supported because Ethernet IP is a readily available communication option for the FANUC robot. Lastly, most Ethernet based components come with Web servers. This was important for remotely supporting the cell over a secure virtual private network (VPN). Although web servers are not used for process data, they have proven to be a valuable troubleshooting tool for engineers and technicians. With an eye toward the future, most specialty analytical equipment has an Ethernet-based communication option using various industrial protocols. Using Ethernet gave our client options to integrate well with future technology.

With the process and safety control components wired and networked back to the safety PLC, attention was turned to collecting data and interfacing with the operator. It is always a good practice to control the network traffic when networking a production system that interfaces with a plant network. For example, this can be done using a managed Ethernet switch to keep local network traffic from the VFDs, Point IO, and robot from being broadcast across the plant network. The managed switch can be programmed to route or guide network traffic from its source to the intended target device without broadcasting it across the entire network. In this case, there was the added overhead of safety devices and commands running between the internal cell equipment, so a second physically separate network was created to handle the graphical interface and data collection.

Again, an Ethernet network was selected to communicate between the safety PLC, PanelView Plus graphical interface, and Ignition SCADA. This also was the network that the firewall encryption appliances were connected to in support of remote access for troubleshooting.

Unlike the internal process and safety network, the graphical interface and data collection network did not require redundancy. Even though redundancy was not required, we still had to contend with a data collection and retrieval standard published by SAE for the aerospace industry called AMS-2750D. These standards are enforced by National Aerospace and Defense Contractors Accreditation Program (NADCAP). The particulars of AMS-2750 are not important to this topic, but it’s worth noting that the data collection solution can be built to support the standard or other data collection and reporting requirements. In this case, it was known that the new AMS-2750E standard was coming in 2015 and could be planned for. If you have the means, contact the governing body and discuss what changes to the standard might be coming to determine how your system will make allowances.

As development of the graphical interface and data collection was occurring in 2013, it became known that a new AMS-2750E standard was coming in 2015. Even though the cell would be commissioned in 2014, it was important to plan ahead for the new standard since the changes would have a significant impact on how data was collected, as well as the rules governing data storage. The budgeted solution was to use a PanelView Plus V6 with the new ActiveX data collection feature, which delivered data in a CSV data file format. Knowing that in the near future our client would require a data collection upgrade, the PanelView Plus data collection strategy was developed so that it could be scaled up to a future SCADA to support the new standard.

For data to be beneficial, it must have context. For example, what would you find more useful: 24/7 data collection for every process parameter in your operation with a time and date stamp or the same 24/7 data with a lot number or SKU of the product being produced? The SKU or lot code adds a level of context and helps confirm the beginning of one campaign and the end of the previous.

With this in mind, a place was created where operators could enter the lot code and number of parts that would be produced through the PanelView Plus. This was the beginning of a genealogy process for this particular cell. In the genealogy, the number of parts entering the cell was tracked, as were the number that exited along with all the critical process parameters for each lot. Some of these parameters included how long each part was heated, the minimum and maximum temperature the part was held at, the minimum and maximum carbon potential of the atmosphere, and quench time and quench oil temperature, to name a few.

The data was in a CSV file format could be stored for process verification in support of the old AMS-2750D standard. The data was logged at time intervals as low as once per second, with all data coming from the PLC via the Ethernet network using the Ethernet IP protocol.

This year brought with it the new AMS-2750E standard and new challenges to our data collection approach, namely increased resolution and data integrity. Although our resolution using a CSV file was adequate, data integrity was beyond the capabilities of a simple CSV file; a database was needed. With plenty of SCADA packages to choose from, we took into account performance, cost, the client’s ability to support themselves, the requirement for 100 years of storage, and the need for data integrity without having to create a custom application. Our solution was to use the Inductive Automation Ignition platform. The draw was that this commercial SCADA platform could sit on a standard database such as Oracle or Microsoft’s SQL database. For our application, we choose Microsoft’s SQL Standard Edition for Ignition. This gave us a very reasonable licensing fee with Ignition, while Microsoft’s SQL database provided the necessary data integrity and peace of mind that the database software would be supported for many years to come.

When it came to implementing the solution, the data collection strategy was created ahead of time through the PanelView Plus. Again, advantage was taken through using our Ethernet network and the use of the Ethernet IP protocol to route critical the required critical process points along with the manually entered lot information to Ignition. Data integrity rules were enabled to make sure any changes to the data were tracked including the data value before the change, after the change, who changed the data and when. The server was set up to store data on the cell until the hard drives ran out of space. A store and forward routine was also implemented. In the event that the server went down or network communication to the server was lost, data would continue to spool locally at the control panel until the database communication was present. Once communication was established, the locally stored data would be uploaded to the SQL server, eliminating gaps in the data.

Finally, attention was turned to reporting, since data is only as useful as the manner in which it is presented. For our application, the client needed to create both external and internal reports about the production process. The external reports summarized the process parameters that encompassed the manufacturing campaign for a particular lot number. Once the critical control points were identified, a simple one-page pass/fail report was created which illustrated the acceptable ranges for the process, and the most extreme process value that a part was exposed to in that run. Internal reports varied based on the stakeholder. It was found that the most-used report was the simplest to create. An operator or supervisor could set a date range or enter in a lot code to export the data into a CSV file for that run. Once in the CSV format, Excel could be used for more advanced analysis. Should a particular analysis technique become common place, a new report could be created to perform the analysis.

The SCADA portion of many projects is where you can be creative with how you spend your capital. In our case, the client budgeted for a dedicated SCADA server to support the process. On many occasions, the local IT group has much of the infrastructure needed to set up a SCADA platform. Most plants have a physical network server running multiple virtual machines (VM). The resources a SCADA server requires for a typical installation are very reasonable. I have found a well-placed conversation with IT will get us a slice on their virtual server just for the SCADA application, saving the cost of a new server.

In addition, working with the local IT group can help in setting up a V-LAN for industrial servers, safety PLCs, robots, and network instruments to reside on. This saves the cost of creating new physical network infrastructure in the plant to support process automation by taking advantage of existing infrastructure. One of the greatest long-term values in working with IT is the infrastructure support and data backup. With the SCADA software residing on ITs assets, the VM is generally covered by the backup solution taking care of the other VMs supporting the business functions. Working with IT, we also have been able to leverage corporate licensing agreements for the Oracle or SQL software needed on some occasions.