Approaches to network-enabling factory and sensor equipment are typically focused on connecting equipment "A" to workstation "B" over network "C." That's all fine and well, but at the end of the day, if the data isn't used, it doesn't matter. It all starts with connecting the equipment to the network. Choosing the right technology provides a path for future capability enhancements. Actually, getting the data delivered over the network is often left to the IT professionals, but a basic understanding of the architectures is fundamental to getting the right capability out of the network. At the end of the day, unless there's compelling application of the data to real problems, it's a pointless exercise. The whole reason to extend access to industrial equipment is to provide a value to the enterprise.
Connecting to the Data Source
One of the biggest misperceptions of a wired network over a wireless network is the range. Wire seems so much more capable of carrying signals than the air, although, in practice, the range limitations are similar. For the last 100 meters, wireless networks are much more flexible in terms of installation and changes than wired networks.
IEEE 802.3, the Ethernet standard, specifies the maximum length of a twisted-pair segment to be 100 meters. From that point, a switch or repeater is required to transport the signal further. For wireless networks, the national regulatory bodies (such as the FCC in the U.S.) have restrictions on the amount of power and modulation techniques for the radio. Depending on the propagation environment (indoors or outdoors) an IEEE 802.11b (WiFi) network can have a range from 60 to 100 meters indoors, and over 300 meters in warehouses or outdoors with an omnidirectional antenna. With a directional antenna, the range can be over 2 miles, significantly exceeding the practical distances of Ethernet.
While the equipment costs of a WiFi installation are typically higher than a wired Ethernet network, the installation costs are normally lower. The labor costs involved in running a datacomm cable to each piece of equipment on the factory floor can be quite high, especially when there is no existing datacomm infrastructure. Once the facility has been wired, any equipment changes incur additional wiring costs. WiFi networks don't have these costs for installation and changes. The same installed WiFi equipment can be moved without additional labor for cabling.
Given the range, cost, and installation issues, WiFi is often the best choice for connecting equipment and sensors to a network. Since most of the information has to be ultimately connected to an Ethernet network for transport to its ultimate destination, a local server or over the Internet, WiFi makes sense as the wireless technology of choice. Data is kept in an IEEE 802.3-type packet from the source to the ultimate destination, using an industry- standard infrastructure.
Delivering the Data
In networking parlance, there are servers that provide services when requested, and there are clients that request services. These services can be the data itself or storage of the data. There are three basic network architectures to get data from the source (equipment or sensors) to the ultimate user of the data on the network. The equipment may be a server to a client on the network, the equipment may be a client to a server on the network, or the equipment may be a web server to a browser on the network. Each of these architectures has distinct advantages and the best architecture for the application will depend on how the data is to be used.
When the equipment is a server to a network client, it is called a "Pull" architecture. The network client initiates data transfers and "pulls" data from the server attached to the equipment or sensor when required. The network client is often a custom program for interacting with the data. In the traditional Industrial Control marketplace, the equipment is usually an OPC (OLE for Process Control) server, and the client is a SCADA (Supervisory Control and Data Acquisition) application. In some cases, a word processor or spreadsheet can be the client and collect data from the equipment for directly generating reports. The "Pull" architecture is best used when data or control access to the equipment is only needed periodically.
When the equipment is a client to a network server, it is called a "Push" architecture. The equipment or sensor has data that needs to be delivered, and the equipment initiates the transfer. The network server may be a custom application for monitoring the equipment, or it can be a database server that stores the data for future analysis. The typical environment for this architecture is for alerts and alarms, or recording status changes for future records or analysis. The "Push" architecture is best used when the equipment has a stream of data, or decides locally when data is available for use.
The equipment interface as a web server is a special case of a "Pull" network. In this case, the standardized web browser on the network client is able to present a portable graphical MMI to the equipment data. The interface is portable because there are a wide variety of computers and operating systems that have standardized W3C (World-Wide Web Consortium) browsers either built-in or available. Whether the client is a PC, MAC, Unix or Linux machine, or just a browser terminal, they can all access and display the graphical interface provided by a web server, even an embedded web server. The web pages can be simple text and pictures for an operations or debugging manual, or complex data-driven pages for graphs, settings, and current measurements. The use of a standardized interface, the browser, allows this architecture to be easily used from any location over the Internet.
Using the Data
What good is providing access to the equipment if there isn't a good business case for spending the money? There are several compelling reasons to connect equipment over a network. Since equipment can be configured electronically (through a serial port), it makes sense to use a network to allow remote equipment configuration. Similarly, the current equipment operating status can be accessed without being physically close. The equipment operational history can be retrieved and stored for later analysis or recordkeeping. For configuration and status, networked equipment can be interactively diagnosed remotely, leveraging technical resources geographically.
In addition to a local operator interface, most modern equipment has some capability of being electronically configured. At a minimum there is a serial port. Equipment configurations and recipes can be developed and stored on the network, and deployed over the network to the equipment when required. This allows for a quick and consistent configuration of the equipment, and minimizes the human error involved in machine settings. This is especially helpful in high-mix or quick turnaround environments where configurations change frequently. Centrally managing configurations ensures greater repeatability and less setup and verification time for the organization.
Light bars are wonderful in the factory environment. They quickly give operational status of the equipment with a glance. The only problem is, you have to look at them. A condition requiring attention may go unnoticed because the operators are working elsewhere. With a network connection, operational status can be relayed virtually anywhere as soon as a change is noticed. Standard email messages cannot only be sent to an "inbox" on a desktop, but can also be sent to cell phones and pagers as text messages. This allows equipment to directly communicate with the operator required to resolve the issue.
There are several industries where product and process traceability is a requirement. Both the food services and medical industries require traceability of product back to the process. Using a "Push" architecture, process equipment can send its operating conditions and status to a database for recordkeeping and later analysis. If quality control finds an issue, it can be traced back in time to the process state when the product was made. This allows much better analysis of the process parameters that lead to the issue, and helps to identify solutions to prevent recurrence.
"Line 3 is down" usually sends a cold shiver down the spine of any process engineer, and makes the blood boil in Operations Management. The quicker the problem can be isolated and identified, the sooner the line will be back up and operational. When the process engineer can immediately examine the status of the equipment from his desktop, he can instantly begin to solve the problem. With networked equipment accessible over the Internet, that 2:00 a.m. phone call can be dealt with immediately, without travel delays associated with having to be physically present.
Wireless networks add the benefit of technicians and engineers being able to connect directly to the machine, without having to "plug-in." Notebook and handheld computers with off-the-shelf WiFi adapters can communicate directly with the equipment, right on the shop floor. This brings all of the desktop tools right to the equipment, further enhancing the configuration and diagnostic capabilities.
Conclusion
There are compelling business cases for network-enabling industrial equipment. Standard networks extend equipment accessibility not only outside the shop floor into the office, but also beyond the building to different sites. This ability allows creative organizations to leverage their resources geographically. Because the IT industry has already developed the architectures to move and manipulate this information, there is much less R & D required to deploy solutions. Wireless WiFi networking makes sense because it has all of the advantages of Ethernet, without the cabling and access limitations.
