Should Machine-to-Machine Scare Us?

Will Implementing Device-Level Networks and Ethernet in Machines Help Your Customers?

By Control Design Staff

1 of 2 < 1 | 2 View on one page

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

Supervisory System Preferable
There are certainly scenarios for which M2M communication is the most-effective configuration to help monitor machine performance. With lines requiring two or three machines to be close coupled, for example, hard coding is generally the best way to ensure they act as a single unit.When it comes to traffic for machines using M2M in this way, the limitation we see isn't related to the network — engineers using Ethernet to transfer data simply aren't running out of bandwidth. Instead, we find the difficulties experienced are associated with the ease of use of the system. With M2M, everything is hard-coded, which often causes cascading oscillations. One small bump up front cascades through the line and causes more-significant problems.

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
  • 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.

1 of 2 < 1 | 2 View on one page
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments