Ethernet-Powerlink (EPL) uses a similar approach, but a master manager node
handles the synchronization by sending packets at the appropriate time (Fig.
6). Each device checks for these packets and responds accordingly with standard
Ethernet traffic occurring during the asynchronous interval. The idle time between
cycles is small but similar to that found in other time-critical Ethernet implementations.
EPL's advantage is that it uses standard Ethernet equipment and interfaces,
but the protocol stacks must be modified to manage the additional handshaking.
It can handle transmission cycles of 200 ms with station synchronicity jitter
of 1 ms. For even tighter timing constraints, designers can turn to EtherCAT
or SERCOS-III. These are better by an order of magnitude. Keep in mind that
they require custom hardware at each node to handle more critical timing issues.
EtherCAT goes one step further by packing multiple messages within a single
Ethernet packet (Fig. 7). The packets
are forwarded through each node that inserts or extracts information. EtherCAT
also uses an FPGA to handle its more sophisticated Ethernet implementation.
It's often worth the extra cost, since EtherCAT is the implementation with the
fastest response and cycle time.
EtherCAT can handle regular Ethernet traffic as well. EtherCAT routers, gateways,
or switches are required for traffic to traverse non-EtherCAT subnets. Time
synchronization isn't available on these other subnets, but it's still possible
to send EtherCAT packets with multiple data messages across non-EtherCAT subnets,
thereby improving overall transmission efficiency.
First-generation SERCOS, which supported 2- and 4-Mbit/s transfer rates, mainly
was used in machine tool applications. SERCOS-III follows the other industrial
Ethernet implementations with 100-Mbit/s Fast Ethernet support. On the other
hand, it diverges from the standard hub architecture of Ethernet and implements
a dual, counter-rotating, self-healing ring.
This eliminates the need for off-the-shelf compatibility. It also means custom
implementations at the node level. SERCOSIII is designed to provide better performance,
as well as compatibility with SERCOS. Moving conventional Ethernet traffic into
and out of these loops is possible, but SERCOS-III likely will remain on the
industrial floor with a standard Ethernet as a corporate backbone. A linear
version of SERCOS-III is possible, but it lacks the redundancy of the dual loop.
NOTHING BUT ETHERNET?
It isn't feasible for many applications to employ only Ethernet. Remember that
Ethernet is faster than the legacy fieldbus implementations, so even industrial
Ethernet versions that lack heavy duty, real-time performance will be more than
adequate to meet many industrial-control tasks.
Yet the performance and capacity of Ethernet-equipped microcontrollers continue
to grow, making it possible to easily incorporate both non-standard or extended
Ethernet protocol stacks, as well as the higher-level protocols such as CIP.
These are often larger than the basic communication protocol stacks, but their
size can vary depending on the features that will reside on a node.
Still, Ethernet is likely to remain a complementary network, because many control
applications are neither power nor performance restricted. Also, fieldbus interfaces
like CAN will be more than sufficient for industrial control needs at the bottom
of the pyramid. Ethernet may exist all through the hierarchy, allowing mixtures
like CANopen, SERCOS on EPL, or Modbus-TCP.
Of course, the possibility of various standards to coexist must be tempered
by the vendor implementations that often add a proprietary twist, which prevents
interoperability in a mixed-vendor environment. This prevailed with the legacy
fieldbus standards and has occurred at the Ethernet level.
Usually, it leads to a vendor-homogeneous environment—at least at the
subnet level, given the critical nature of most industrial control systems.
Still, the use of a common standard such as Ethernet has brought vendors significantly
closer to each other with respect to standards, simply because of the need for
interoperability with other fieldbus protocol standards.