Several of the engineers implementing device-level networks and Ethernet in our machines want more machine-to-machine communication capabilities to supposedly help our customers. Some of our managers are concerned that M2M traffic could quickly grow beyond our customers' ability to monitor and control it, and so M2M might actually hinder machine control performance instead of help it. Does anyone have some advice on monitoring and controlling, so we can all get on the same page, and help our customers?
—From March '13 Control Design
SEE ALSO: Let the Machines Talk
Offering customers the latest technologies is one way we try to make a name for ourselves, and improve their operations. We've normally been pretty traditional with our sensor technology, but suppliers are pushing imaging solutions more aggressively since cost is becoming less of an issue. We like the added versatility an image sensor might offer. The machines operate in an environment that varies significantly in temperature and humidity, so we’re unsure how precision and accuracy will compare. Anyone have observations, experiences, to share?
Send us your comments, suggestions or solutions for this problem.
An alternative — especially for multi-machine and multi-cell applications — is to deploy a configurable line-control application that uses a supervisory system to control and analyze the performance of an entire line, allowing it to operate as a single unit. Not only does this approach lower the total cost of deploying and optimizing equipment, it also provides a platform that interfaces with production machines and operations management systems in a consistent manner.
A supervisor-based system offers features that extend beyond what traditional M2M offers for configuration, control and performance reporting:
- Configurable upstream/downstream interlocks and start/stop behaviors
- Ability to manage each line configuration on a product type/SKU basis
- Display of real-time status and performance information
- Display of line-level key performance indicators (KPI) and root-cause analysis
- Reason reporting for equipment downtime by duration and frequency
- Programmatic creation of reason code descriptions from event messaging structure
- Ability to create and organize ad hoc reports against SKU, shift, work order, user, etc.
For machine builders, the main benefit of an end user implementing a line-control solution is that it can be done without impacting an individual machine builders' control system or changing how they program. The application reconciles customization at the equipment level so that all line control functions and systems connected to it can be standardized and made highly configurable. Industry standards are leveraged when they exist, but the end user isn't dependent on them to achieve consistent results.
Ryan Lepp,
business manager,
Rockwell Automation
Taste This Flavor of Ethernet
There are certainly software solutions or services a vendor would happily sell you to help manage a chaotic situation with M2M traffic. Rather than opening up your wallet a second time, the best solution is to select the right device-level network, which also happens to mean the right Ethernet solution. You can avoid the introduction of negative M2M traffic to the network using EtherCAT because that take on industrial Ethernet has several advantages in cabling and diagnostics that prevent M2M headaches in the first place.
For example, networks such as EtherNet/IP or Modbus are designed to be switched network environments, but these protocols by nature are inherently noisy and this noise must be mitigated using expensive, managed switches. Beyond the financial burden, this can cause the kinds of monitoring and control issues the reader speaks of. On the other hand, EtherCAT does not require switches and has a functional principle called processing-on-the-fly, which means that each individual EtherCAT device — from controllers, to drives to I/O terminals — process the EtherCAT frame as it passes through the network.
With EtherCAT, there is no broadcasting/polling of the network from the master controller to slave devices as you see in other iterations of industrial Ethernet. Because one EtherCAT master can control 65,535 devices, it can easily control an entire machine line, negating the need for M2M communication within that line. EtherCAT also features a vast array of diagnostic features built in with no added fee to the system. For example, users can view the real-time health status of any given node at any time. Users can see bad connections or cable breaks right at the ASIC of any EtherCAT device. The design of EtherCAT also implements cabling redundancy so that if a node drops because of some external event, the entire line won't go down and most of the network will continue to run. This can make a significant positive impact not just on M2M communications, but on machine uptime in general.
Nathan Eisel,
technical support manager,
Beckhoff Automation
No, Taste This Flavor
As plant floors evolve away from fieldbus toward more-open technologies such as Ethernet, questions arise regarding how to manage the traffic on the network. When it comes to machine-to-machine communication, many solutions are available. However, not all solutions are created equal. Traditionally, machine-to-machine communications required an interface between the machines. That interface could be software programming blocks that sent and received data. It also could be a hardware device such a network coupler that acted as a slave to both machines and where data was exchanged. Nonetheless, the traditional solution of machine-to-machine communication typically required manual communication block programming or the added cost of physical hardware to act as the interface.
By moving toward Ethernet, engineers expect better solutions for machine-to-machine communications challenges. This is where Profinet has taken the lead. With Profinet iDevice (intelligent device), a controller can map part of its process image table as addressable I/O for another controller. As a result, this system can have two controllers exchanging data without the need for programming or additional hardware. The iDevice functionality is a simple check box and a table where inputs and outputs are mapped. Once a controller is configured as an iDevice, it can be assigned to another Profinet controller as an I/O drop. All communication happens at I/O speeds and therefore requires less overhead and management than traditional TCP/IP traffic. The iDevice functionality eliminates the need to monitor and manage TCP/IP traffic and reduces the potential complexity of machine-to-machine communication.
Ming Ng,
Profinet Technology Manager,
Siemens Industry
Consider Bluetooth
Bluetooth machine-to-machine communication/coordination could be a viable option for this application. Security is ensured via device-matching technology, data encryption and up to a 16-character, case-sensitive access code (95 bits of entropy). Bluetooth is also familiar, reliable and industry-proven to work in metallic-intensive applications, e.g., foundries or high-bay warehouses. M2M via Bluetooth can shed a lot of costs upfront by eliminating large runs of cabling, and down-the-road because the cabling won't require maintenance or troubleshooting.
Additionally, assigning wireless M2M traffic to drop-in I/O, such as Wago's Bluetooth RF-Transceiver, will not bog down your customer's Ethernet network. This alone should allay any long-term concerns about managing network traffic because it won't be Ethernet-based. In fact, advanced Ethernet controllers featuring integrated web servers can put everyone on the same web page. Example: Information exchanged between machines via Bluetooth can be used to develop OEE reporting. Our Bluetooth RF-transceivers can route select machine/production metrics to a Wago PLC. The PLC's web server can prep the OEE data for a web page that's accessible to entire departments, or even the whole organization. Both you and the end-customer can get comprehensive monitoring capabilities that are not resource-intensive and conserve Ethernet network bandwidth.
Charlie Norz,
product manager - Wago-I/O-System,
Wago
Do Your Homework
A lot of this has to do with machine control architecture, hardware being used, application requirements (especially related to response time), etc. I can make some assumptions, though, and provide a general answer. I assume each machine has its own controller, and also uses a network for local machine peripheral devices.
The local networks for the machines have a high level of determinism, and are real-time networks. Most often they are cyclic in function. The M2M data must be analyzed, and a determination must be made, if it also must be real-time cyclic data, or if it can be event-driven.
For M2M data that can be event-driven, this should not be used in a message type that is cyclic, with fast intervals. Many industrial networks today can support multiple message types designed for cyclic and event-based data. CIP protocols are an example. In both DeviceNet and EtherNet/IP, implicit polled messaging (cyclic) and explicit messaging (event-driven) can coexist on the same cable. These two examples are device-level and Ethernet-based, respectively, but have similar mechanisms for this purpose. Putting event-driven messaging in an appropriate message type reduces the burden on bandwidth, and will be less likely to disrupt machine performance. This type of M2M data might be for monitoring machine levels, maybe reporting a case if a temperature is exceeded, or that a queue is full.
If the M2M data must be in real time, the network must have the bandwidth necessary to support the local traffic plus M2M traffic. This is very dependent on the hardware used. Most Ethernet-based industrial protocols with a proper infrastructure (i.e., managed switches) have the necessary bandwidth to manage control and monitoring data, including M2M traffic. Device-level networks have less bandwidth, but might have other mechanisms like change-of-state that optimize performance, so they can also handle the combined traffic.
My advice would be to do your homework first. Analyze the application data, decide which data is cyclic, and which can be event-driven. Does your hardware of choice have the bandwidth to carry your data? Does it support functions needed to optimize the bandwidth, such as putting non-critical data in an event-triggered message, or a very slow cycle? By doing this properly in the beginning, I'm sure that M2M traffic can be managed, and will not hinder machine control performance.
We have a real example that uses our valve terminal with EtherNet/IP. The I/O data on the terminal is implicit-type polled data, and the cycle could be every 10 ms, for example. The terminal also could be configured to report that the supply pressure is out of range. If this event happens, the controller could pull the specific data out of the terminal and report this to other machines, HMIs throughout the machine, or an operator station. Other machines might benefit from this information, but the impact to the bandwidth is negligible because this event might happen rarely, so the message is rarely sent.
Frank Latino,
product manager,
Festo
