There has been much discussion recently regarding the applicability of using Ethernet at various levels of the control hierarchy. Since Ethernet is so prevalent in the office and is frequently used as the enterprise network for high-end controllers, it would seem to be natural to use Ethernet at the control level or even at the device level as proposed by some in our industry. The arguments for its application include low cost, good connectivity and simple migration to higher speed networks. The cry to use "standard" Ethernet for control applications requires an understanding of the fundamentals of Ethernet.
Multi-segment Ethernet networks can be constructed by using repeaters and hubs. A segment is defined as a length of cable consisting of one or more cable sections and associated connectors with each end terminating in its characteristic impedance. For example with 10BASE5, the segment represents the complete end-to-end length of thick coaxial cable even though several medium attachment units (MAUs) are clamped onto the cable. The maximum length of a 10BASE5 segment is 500 m and this would represent the network diameter of the Ethernet network if no repeaters were used. However, Ethernet can be expanded to a larger network diameter by using repeaters as long as the network diameter does not exceed the collision domain of Ethernet.
The question was, "Could Ethernet operate at 100 Mbps?" The answer was "yes," but there were competing approaches to Fast Ethernet. One approach was not to make any changes at all, just scale the protocol to 100 Mbps. This would provide backward compatibility and was favored by most vendors. The second approach favored a redesign of the medium access control (MAC) in order to gain a feature called demand-priority at the sake of backward compatibility. In the end the "technically elegant" demand-priority solution, which utilized a token-passing protocol, lost out both in the IEEE 802.3 committee and in the marketplace. Introduced as 100VG-AnyLAN, the technology never gained widespread support outside its two proponents, Hewlett Packard and AT&T. Although the words "Fast Ethernet" are not used, the IEEE 802.3u was adopted as the Fast Ethernet standard in 1995.
The network diameter of an Ethernet network can be increased using repeaters as long as the network diameter does not exceed the collision domain of Ethernet. All Ethernet nodes must be able to recognize the occurrence of a collision regardless of the physical location of the nodes since the detection of collisions is fundamental in the manner Ethernet arbitrates media access. In this lesson, the concept of switching will be introduced as an alternative to the deployment of repeaters. Switches can not only increase the overall network diameter, but will improve the performance of Ethernet networks as well.
In previous lessons, we discussed traditional Ethernet and its dependency on repeater sets to expand the length of these networks. As Ethernet evolved to incorporate twisted-pair cabling and star topology, a repeating hub was necessary in order to connect the various link segments together. With the introduction of switching hubs as a replacement for repeating hubs, network performance was enhanced by breaking up one collision domain into several collision domains. However, is it necessary for modern Ethernet networks to only incorporate switches? The answer is no. Repeating hubs have their place, but you must understand the tradeoffs when not selecting switch technology.
The push to incorporate Industrial Ethernet or even "plain vanilla" Ethernet into control networks implies that by making that choice completes the selection process. As mentioned in a previous lesson, Ethernet II and IEEE 802.3 are strictly data link layer technologies which do not guarantee the delivery of messages over a network or between networks. Protocol stacks such as TCP/IP or SPX/IPX provide that functionality and without them Ethernet would be useless. With the immense interest in the Internet and the potential of attaching control networks to the Internet, the protocol stack of choice is TCP/IP because it provides the foundation for the Internet. This lesson addresses issues related to the IP portion of the TCP/IP stack as it applies to control networks.
IP resides at the network layer of the OSI communications model and provides the basic unit of data transfer, which includes addressing, routing, and fragmentation. The transport layer of this same model resides above the network layer and provides station-to-station communication and a common interface to the application layer. This implies reliable communication, which is either accomplished at the transport layer or at the application layer. With control networks, this is usually accomplished at the application layer since many control networks were designed before the popularity of TCP/IP took hold. Still, there are some control network protocols, such as MODBUS/TCP, which do rely upon the guaranteed delivery mechanism of TCP and there may be more in the future. Actually, at the transport layer of the TCP/IP stack there are two transport protocols, each of which find service in control networks. The User Datagram Protocol (UDP) and the Transmission Control Protocol (TCP) will both be discussed in this lesson.
In a previous lesson we discussed the Internet Protocol and the structure of IP addresses. An IP address identifies the source and destination of a directed or unicast message and is defined in RFC 761. IPv4 is the most common version of IP addressing requiring 32-bit addresses. Although IPv6, the 128-bit version, will be used in the future, this lesson will restrict the discussion to IPv4. IPv6 was developed because the explosive growth of the Internet will soon deplete the inventory of available addresses. At one time, 32-bit addresses seemed to provide more than enough addresses but there was much waste in initial assignments and the class structure of IP addresses was inefficient. In order to make more efficient usage of IP address, the concept of subnetting was introduced with RFC 950. This lesson introduces this concept.
One of the numerous acronyms from the Internet world is SNMP which stands for Simple Network Management Protocol. Of course, anything termed "simple" is suspect. SNMP is an Internet protocol for managing devices on IP networks. Usually people think SNMP only applies to managed Ethernet switches, but it can be applied to any device that supports IP or TCP protocols. This includes printers, workstations, servers, modems and even industrial I/O devices. SNMP introduces us to the concept of "managed" devices which offers numerous advantages over unmanaged devices and could prove beneficial in industrial applications. As more and more devices embrace Ethernet, adding SNMP support can lead to greater advantages.
