I helped start Chrysler's JOINT VENTURE with Mitsubishi, Diamond-Star Motors here in Bloomington-Normal, Illinois, in the 1980s as a PLC programmer. They had Mitsubishi PLCs and ran proprietary bus networks such as MilsecNet, which was similar to Data Highway and DH+.
The body shop was thought to be the bottle-neck of the plant, so the idea of a monitoring system to help with identifying problems was put forth, and I took the project. Citect SCADA software was used to gather the data, and present reports and graphics screens depicting the process in real time as it ran. This solution was successful, and I even got to write an article about it, "Automating the Most Automated Car Plant in the World," in the January 1993 issue of Industrial Computing magazine (http://tinyurl.com/l6h6aht).
In 1994, I went to work for Springfield Electric Supply to help create an automation division called Springfield Automation. In 2000, I started my system integration company, SCADAware, and it diversified with projects in manufacturing, food and beverage, water/wastewater, pipelines, power systems and control, and more.
During this time, a large, midwestern heavy-equipment manufacturer asked us to develop a data acquisition (DAQ) and monitoring system similar to what we'd done at Diamond-Star. However, there weren't any packaged OEE reporting packages back then, so we used a SCADA solution similar to that at the automotive plant.
The equipment builder had a lot of Allen-Bradley and Modicon PLCs, and its machine shop had a lot of CNC machine tools that were harder to talk to because they had proprietary controls, and we couldn't connect to them. So we had to mount shoebox PLCs and/or slice I/O devices from Wago on these machines, and locate signals to use as digital inputs on these small PLCs that were then connected to the LAN for data acquisition. This is still a problem today. It's only in the past few years that CNC machines are getting networking links via MTConnect, but there still don't seem to be many builders embracing open communication to their controllers.
Also Read: The Beauty of Single-Point Control Systems
Of course, the Internet and web browsers began to arrive in the mid-1990s, all monitoring and SCADA systems moved to browser-based systems in the late 1990s, and now Ethernet and the Internet are everywhere.
In 2005, the large equipment manufacturer's research group wanted to build a standardized, commercial DAQ and monitoring product, so we partnered with them to develop our StatusWatch software, which is a flexible, OEE reporting tool that lets users make their own reports using a browser without any third-party reporting tools. We even have an iPad app for it.
The catch is that our monitoring systems and applications have to rely on users' network infrastructures and IT groups. Some bigger firms have segmented and firewalled networks, but most users still have one big, open-collision domain network. So even though we've become more product-oriented, installing a monitoring system like StatusWatch on a customer's server means we still have to go in, jump on their equipment, document their network, make sure they have a reliable network, enough computer processing power, memory and hard drive space, and recommend fixes to their systems.
Our main network requirements are Category 5e/6 (ANSI/TIA/EIA 568-B or ISO/IEC 11801) cables; maximum 100-m cable lengths, 100 Mbps connection speed, minimum latency of 100 ms from shop floor network to data collector, and a dedicated subnet for the shop floor.
Likewise, wireless has to start with a good site survey and audit. Our wireless requirements are 2.4 GHz, 802.11 b/g Wi-Fi with supported encryption protocols, including WPA-PSK, WPA2-PSK/TKIP, CCMP, WPA-EAP (PEAP, TLS, TTLS) and IEEE 802.1X.
Users always can find and select a useful monitoring product, controls or other application technology, but they all depend on having a good network infrastructure to support them.
Rick Caldwell is president of SCADAware in Bloomington, Illinois. To learn more, visit www.SCADAware.com.