Automation issues: SCADA and surveys

Lord Corporation, Erie, PA, produces parts for the aerospace industry. They must be manufactured to precise standards and are unusable if specific production data are not available. The company is required by the FAA to collect and maintain detailed records. In the past, it kept those records by hand.

Lord’s Mechanical Products Division embarked on a multiphase project to develop a plantwide supervisory control and data acquisition (SCADA) system to provide the control, links to manufacturing standards, and data collection required by its customers. Its goal was to provide a plantwide system with a common entry point for all machine setup parameters that could be easily maintained. It was also necessary for the networked system to provide a common point of data collection and review for all operations in the plant.

Lord investigated technology that could be used to link these islands of automation. The company consulted JDC Systems Company, an Erie, PA-based systems integrator, for a plant systems review, system architecture recommendations, and implementation scenarios.

The investigation phase revealed that the new system would have to satisfy the following criteria:

• A storage and interface system was necessary to keep setup information for the machines connected to the systems.

• The ability to integrate barcode technology for the retrieval of setup information from central data warehousing was desired. A local barcode reader would scan travelers that accompany parts to each production station. The scanning operation is a trigger to retrieve the appropriate setup data from the database and insert the retrieved information into the appropriate machine setup locations.

• Also necessary was a flexible data collection tool that provides the ability to watch incoming data in real time, review historical data, compare sets of collected data, and store data to a variety of databases.

• Web/intranet access was needed. This system would offer a viewing platform across the company that would be common to all users without requiring the maintenance of traditional “thick” or fully installed software applications at each viewing node. In addition to a common look and feel, this type of interface would provide viewing via a familiar interface using any web browser. Finally, it would provide an easily maintainable system that would reflect updates across a network with changes occurring at the SCADA server.

• The systems integrator began a plantwide audit of individual machines and processes that would be included in the system. It learned that Lord had put together a strong base of common equipment in various parts of the plant. While this commonality had served Lord well in the past, it presented a unique challenge when it came to bringing the hardware together across a common communications medium. These computerized machines did not exchange information easily, if at all. The challenge was finding a healthy medium that would give the company what it required for the new system while maintaining its investment in existing plant hardware.

  The plant communication system had to be one that could handle large amounts of data traffic without disrupting the control of any individual part of the system. This system would be used to collect a great deal of production information at different intervals and in differing degrees of density. There would be other traffic on the network in the form of the machine setup information. This information would now be centrally stored where it could be easily maintained. When requested by operators via a bar code scan, this information would now be sent in bulk to the appropriate setup registers at the floor controllers.

  Based on the system’s operational requirements and interconnection capabilities of plant hardware, a 10-Base-T Ethernet system was chosen to link the floor to a common SCADA server through OPC (Object Linking and Embedding for Process Control) servers. The OPC communication servers provide the company with the throughput necessary for the system, universal connectivity to the varied floor hardware, and simple connections to Windows software applications. The majority of systems in the plant required only slight modifications to accommodate the new communications. Some systems required additional Ethernet communication cards while others required control processor upgrades, but none of the plant control systems required major modification or alteration.

  The final piece of the SCADA system to be chosen was the application software that would be used to interface to the plant systems and provide interconnection capabilities to the data storage system. Iconics Genesis32 software was chosen as the SCADA software because it most closely met the established criteria and is based on the OPC format, which enables it to work seamlessly with the floor and office environments.

  The system was implemented with no significant disruption of concurrent plant activities. The core application has been running at Lord’s Erie plant since January 2001. Several pieces of equipment have been added to the system, further enabling the plant engineering staff to view and improve the individual processes. Lord personnel can now view and share information across the plant with anyone who might be interested in specific data. The system has already helped the company identify, and thus remove some process bottlenecks.

  … and the survey says:

  According to two recent surveys conducted by Control Engineering magazine, 76% of users rank remote system diagnostics with some level of importance. However, polled separately, vendors offering remote diagnostics report only 27% of users currently take advantage of such services.

  The surveys were conducted during February and March 2001. One survey was conducted online, asking control and automation system users to share information about support service expectations and experiences. The second survey asked control and automation system suppliers to share their support service offerings and experiences.

  Other survey findings include:

  Two thirds (67%) of responding users expect some sort of problem resolution in eight hours or less, while 43% expect resolution in four hours or less. Only 1% of respondents expected these services to be free.

  Nearly 60% of users prefer an unlimited annual service contract, while another 25% indicate they prefer to pay on a per-use basis.

  Users say that 75% of systems (hardware/firmware and software) are either current or only one revision behind the supplier’s current release.

  Two years was the time period that 54% of the responding users expect suppliers to support legacy products, while 55% expect the same time period of support for legacy systems.

  Of responding users, 36% indicated suppliers should support the current and two past major software revisions, with 23% declaring a need for support of five past revisions.

  Nearly 90% of respondents re-port they must keep systems current to receive supplier support, obtain bug fixes, and be able to implement product enhancements.

  Sixty-eight percent say they will keep life-cycle planning services inhouse, seemingly at odds with business executives, who claim they want their companies to focus on what they do best, and partner and/or outsource everything else.

  Suppliers report that 28% of calls/contacts received would be eliminated if users would read available documentation and/or attend training courses.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.