Bill's Blog on Automation

Unexpected Flooding of Switch Ports

On a recent occasion, we had a customer question us about the following confusing situation. An Industrial Ethernet switch had been delivering unicast messages to the proper port for quite awhile when suddenly the messages began flooding to all switch ports.

After a brief investigation, we learned that the customer had been sending a sustained stream of messages to a destination with no acknowledgements from the destination device. The customer had no need of acknowledgement and so had not arranged for a response.

This kind of traffic pattern is seldom encountered and, therefore, rarely causes issues. However, unexpected message flooding can occur under the circumstances that this customer had unwittingly devised. The issue involved the switch address table.

After a MAC address has a prolonged period of inactivity, an Industrial Ethernet switch removes the dormant address from its address table. The switch learns the MAC address of each attached device that transmits to the network. But when a device fails to transmit for a long time, the switch assumes that the device has failed or left the network and so removes the inactive address to improve the efficiency of its address table. This process is called aging and is commonly set to occur after about five minutes.

If you have a situation similar to that described above, you may consider a managed switch. Managed switches generally have the ability to adjust the address table aging time. For example, each model in the several lines of managed switches from Contemporary Controls can have its aging time set to over 12 days.

Using the BACnet® Discovery Tool – BDT

When applying BACnet routers in the field is there a quick way to determine if the router is successfully communicating to attached devices? We think there is with the BACnet Discovery Tool (BDT). Although limited to very simple tasks, it is easy to use — and it is FREE!

The BACnet Discovery Tool (bdt.exe) is a BACnet/IP application for Windows^® that is easy to install and use. It is an excellent means for verifying communication with MS/TP devices that are being accessed through BACnet/IP routers such as those available from Contemporary Controls: the BASRT-B DIN-rail mounted BACnet/IP-to-MS/TP router — or its portable counterpart, the BASRTP-B.

The tool is based on an open source BACnet protocol stack developed by Steve Karg. His project is described at:

http://bacnet.sourceforge.net

At just over 520 kB, bdt.exe is small — making it a snap to download. When you download the tool, you can save and run it from anywhere on your computer's hard drive.

We use BDT with our BACnet Interoperability Board. On this board we mount equipment from different BACnet vendors to prove our routers operate with different equipment configurations. In the photo at the end of this article you will notice mostly Alerton devices being tested, but we can change out equipment as needed. Although we have more elaborate BACnet tools, BDT is a vendor-neutral tool that can quickly discover BACnet devices. To give you an idea on how this works, we configured our board with three MS/TP segments each tied to a dedicated BAS Router. Each BAS Router has its BACnet/IP side tied to a common network through one of our Ethernet switches. Attached to the network is a workstation running BDT.

We launch bdt.exe by double-clicking its filename or icon. As soon as the application starts, it opens in its own window. It immediately activates its Who-Is service and transmits one Who-Is query. If we do not see any response within a few seconds, we can try pinging the IP address of the router to confirm that its IP channel is functional. NOTE: Because bdt.exe sends a BACnet/IP Who-Is (not a BACnet/Ethernet Who-Is) it will not discover any devices which only support BACnet/Ethernet.

Each I-Am response is reported on screen as soon as received. As shown in the screen below, each response also identifies the associated Device Instance number and Vendor identifier. The first three responses are from Contemporary Controls whose vendor number is 245. The remaining devices are identified as manufactured by Alerton whose vendor number is 18.

NOTE: For ease of illustration, the screen capture has been altered so that two lists that actually appear one-after-the-other , are here displayed side-by-side. Also, both lists (the responses on the left and the device information on the right) are abbreviated.

After all of the I-Am responses have been received, bdt.exe summarizes the information it has received as illustrated in the right portion of the sample screen. In this example, you see a list of many respondents on the left. The associated summary list on the right reports each Device Instance, the device’s maximum Application Protocol Data Unit (MaxAPDU) value and the number of the network ( Net) on which it resides. A Net value of 0 represents the network to which the BACnet Discovery Tool is attached — and so it must be an IP network. (This identification is reinforced by a MaxAPDU value of 1476 — typical of an Ethernet network.) Since the first three responses in the device summary on the right show that devices 202162, 202161 and 202160 have Net values of 0, the originators of the first three I-Am messages must be BACnet/IP devices — in this case, they are the three BAS routers.

The second column (MAC) of the summary report on the right, requires detailed explanation. The MAC value is a composite of two pieces of hexadecimal information obtained from the BACnet/IP device involved in each I-Am response. The first eight digits represent the IP address of the BACnet/IP equipment that has delivered the I-Am response. The last four digits report that device’s BACnet/IP UDP port number.

NOTE regarding the MAC value: there is a significant difference between the BACnet/IP protocol (used by bdt.exe) and the BACnet Ethernet protocol. The bdt.exe MAC value is not the Ethernet MAC address as you might expect. This is because BACnet/IP protocol uses the device IP address as the MAC value. Only BACnet Ethernet protocol uses the actual Ethernet MAC address as the MAC value.

The equipment delivering the I-Am response could itself be simply a BACnet/IP device (as is the case with the first three respondents) — or it could a router that is acting as an intermediary for devices on the far side of the router (which is the case with the remaining respondents in our example).

If the response Device Instance is that of an MS/TP device, then the associated MAC information pertains only to the router that delivered the response.

The first response shows device 202162. Its information tells us it is a BACnet/IP device (Net value 0) whose MAC value reported an IP address of 0A0000D9 and a BACnet standard UDP port number of BAC0.

Responses 4 and 5 are for devices 3015 and 3002, respectively. Because these two lines have identical MAC values, their I-Am responses must have passed through the same BACnet/IP router — a fact also indicated by the matching network numbers of 100. In this case the router’s IP address is seen to be C0A85C64 — and the router used UDP port BAC0. NOTE: If you wish to convert the foregoing hexadecimal values into their decimal equivalents, the UDP port is simply 47808. The displayed hexadecimal IP address value converts to a dotted decimal IP address by converting two digits at a time to decimal. In this example, segment C0A85C64 into its quad address hex values: C0-A8-5C-64 — then these four hex pairs convert to 192.168.92.100.

Note that response 6 (for device 3044) passed through a different router that is identified by a MAC value of C0A85C65BAC0, and operating on network number 101. And also see that the final response (for device 3043) passed through yet another router identified by a MAC value of C0A85C66BAC0 and residing on network 102.

Finally, the last line in the sample screen indicates that once you have finished examining its display you can end the application by pressing any key. When you terminate the application, its window closes automatically.

You can download this handy, free application by pointing your browser to:

http://www.ccontrols.com/exe/bdt.exe

BACnet MS/TP MAC Addresses — Any Significance to the Addresses?

There are 256 possible BACnet MS/TP addresses ranging from 0–255, however, you cannot assign a device to 255 since it is reserved as a broadcast address. No device is allowed to have a source address of 255. There is another restriction on addressing. Master devices, those who participate in the token-passing protocol, must be addressed from 0 to 127. Addresses from 128 to 254 are reserved for slaves who do not participate in the token passing — however, they can occupy lower addresses as well. Each MS/TP master must be assigned a unique address in the valid range, but is there any significance to the value of the address? Actually, there is.

If you study Johnson Controls’ (JCI) MS/TP Communications Bus Technical Bulletin, JCI states that MAC address 0 is reserved for bus controllers and cannot be changed. Addresses 1–3 are also reserved. Therefore, field controllers should begin being addressed from 4 on up with no gaps in the sequence. This allows the best possible performance since no time is wasted passing tokens to non-existent devices. Another parameter comes into play and that is Max. Master. This parameter does not mean the maximum number of devices but the highest address used by any master in the network. We know you can only address up to 127 masters — so this is the default value for almost all devices. However, this is not the most efficient setting since the device with the highest address will periodically poll-for-master (PFM) up to the Max Master limit. This is a waste of time if you only have 20 devices addressed from 0–19. Ideally, you would like all devices to have their Max Master set to the address of the highest master address on the network. However, seldom do you see this parameter changed.

There is significance to being the MAC 0 “guy”. By having the lowest possible address, you are the first in line to begin PFM in case there is a network disruption. If you have Max Info Frames set high, and you receive the token, you can quickly flush your queue before the other devices get the token and begin polling for nonexistent devices. So if you are a bus controller or a BACnet/IP to MS/TP router like the BASRT-B, assign yourself MAC 0 for the best performance.

How BACnet Tools Can Help You

Installing BACnet devices can be challenging for a number of reasons. You may be dealing with BACnet/IP, BACnet Ethernet, BACnet MS/TP, BACnet over ARCNET, or a mix of protocols. You might have to cope with repeaters, switches or routers.

Regardless of the complexity of your installation, a BACnet tool can greatly assist you. Although many tools are available over a wide price range, you may not need the fancy options of the expensive tools. You will at least want a tool that will discover BACnet devices (wherever they may be on their networks) and their properties.

A modestly priced choice (sample shown above) is the Windows®-based "BACnet Quick Test" from PolarSoft. It reports Device Instances, Vendor IDs, BACnet objects and associated properties. It confirms that devices are communicating on their networks and allows you to read and write object properties. It works with BACnet Ethernet, ARCNET, BACnet/IP and BACnet MS/TP.

Sometimes it is great help to just know that devices are accessible. A simple "BACnet Discovery Tool" is available for free from Contemporary Controls. Just point your browser to:

www.ccontrols.com/exe/bdt.exe

When You Can't Reach an IP Address

The annoying alert below is often encountered by Firefox users, but it is particularly frustrating in an Ethernet network that contains few devices.

As listed above, the site could be "temporarily unavailable" — a nice way of saying the targeted device is offline, perhaps due to a malfunction. The second suggestion above to "check your computer's network connection" is always good advice. The third caution about a "firewall or proxy" is less likely to be an issue — and usually you are aware of such situations anyway. And for those of you still using Internet Explorer (IE), the alert below gives similar suggestions.

The third suggestion from the IE alert above is perhaps the most significant to Ethernet users. Mistyping is among the most common cause of errors. But here is where you may encounter a most surprising and very simple mistake — one that often goes quite unrecognized until time has been wasted investigating other, more-expected issues.

This common mistake alluded to above occurs when you are careless with your list of network IP addresses. Have you ever failed to realize that you are typing in the very same address of the machine at which you are typing? Yes, making this simple mistake will yield either of the alerts shown above. Before you start checking network connections and other issues, confirm that you are not targeting your own IP address!

Securing Ethernet Communication

Sometimes an issue arises regarding the security of Industrial Ethernet communications. For example, security could be a major concern when Industrial Ethernet messages travel over the same network infrastructure accessible by BAS (Building Automation Systems), office personnel or IT staff. A simple way to provide the needed security is to use a VLAN (Virtual Local Area Network).

A VLAN restricts communication to stations that are VLAN members — non members are not privy to VLAN conversations. There are two basic types of VLANs: Port VLAN and Tagged VLAN (IEEE 802.1Q). Port VLAN, available on some configurable or smart switches, is simple to implement but has limited utility because its area of control is the set of devices attached to a specific switch port. Tagged VLAN, a feature of almost all managed switches, can extend VLAN membership through many switches to stations separated by considerable distances. Therefore, Tagged VLAN is almost always the best choice for Industrial Ethernet security.

Tagged VLAN works by embedding a code segment (the tag) within each Ethernet message. Membership information in the tag allows the message to be sent to only those stations that belong to the VLAN. For this scheme to work, each VLAN member station must attach to an appropriately configured managed switch that has VLAN functionality enabled. But the total communication path could contain unmanaged switches at points where VLAN decision-making would be unneeded.

Typically, a managed switch can accommodate several VLANs, each with its own set of members grouped according to whatever criteria are relevant in the Industrial Ethernet strategy. Thus, configuration of VLANs can generally be as simple or as complex as the situation demands.

Beyond security, other issues arise from mixing Industrial Ethernet with BAS or office networks. BAS traffic can consume a significant portion of available bandwidth. The same can be true of Internet data transfers. VLANs also help in managing the levels of such traffic — segregating bandwidth hogs (Internet downloads and security camera video) from other traffic.

For more information about VLANs, see this document:

  www.ccontrols.com/pdf/Extv5n1.pdf

A Common Switch Mistake

Have you ever installed a switch only to discover that certain communication does not pass through it? One of the most common issues that arises in the installation or reconfiguration of an Industrial Ethernet switching hub (managed or unmanaged) involves the most defining feature of a switch — its address table.

Typically installers attach various CAT5 cables to a switch, power it up and check for initial functionality. Sometimes the initial functionality will be less than perfect for various reasons: a remote device has not been turned on, auto-negotiation was disturbed by some transient condition, initial cable placement needed to be changed, or some other issue caused a glitch.

Any of the issues mentioned above (among many others) could prompt the installer to move a cable from one port to another to see if the second port behaves in the same way as the first one that experienced the problem. Indeed, your natural inclination might be to move a cable from one port to another, then to another, and so on until each port Link LED has been confirmed to glow as expected.

But the port-swapping scenario described above can create headaches because of how the switch address table works. When a source device sends a message through the switch for the first time, the switch learns that the originating device is connected to a specific switch port and the switch records this device/port association in its address table for future use. If you then move that device's cable to another port on the switch, the switch still "thinks" the device is attached to the first port. Consequently, messages bound for the device will be mis-sent to the original port until the switch "realizes" the situation and updates its table — a process that usually takes several minutes. Until the mis-addressing is corrected, you might well think that the switch is defective. Pings to devices that are "lost" due to port swapping will go unanswered until the address table is correct.

If you find yourself confronting this address issue, the situation will self-correct in a few minutes (typically five) — or you can correct it immediately by cycling power to the switch.

Surviving a Broadcast Storm

High levels of broadcast traffic may occur in most Industrial Ethernet networks and can hog available bandwidth, rob CPU time from end devices and in extreme cases may cripple a network. This situation can exist due to improperly set STP or RSTP parameters or malfunctioning PCs or end devices (see The Value of Rate Limiting).

Routers can block broadcasts or other problematic traffic, but they are usually more expensive than switches and, generally, not as fast as switches.

Since some amount of broadcast traffic is likely present on your network, wouldn't you like to know how much is too much? A helpful management feature is rate limiting with which you can control your exposure to these levels of traffic. But the question becomes, "How much traffic can you sustain?" You can create your own traffic generator and then slowly raise the amount of broadcast traffic using rate limiting until you see a problem. This should help you establish the optimal rate limiting levels. You should probably set all message types to this level. Although broadcasts are the most common type of flooded messages you see during a message storm, you can also see directed or multicast messages arriving at a very high rate.

With a managed switch you can "fine tune" your message storm tolerance as described below — if certain precautions are taken. On the PC used as your test station, use a fixed IP address instead of DHCP and disable your firewall.

Procedure: Connect your PC to your LAN via a managed switch. On this switch, loop two ports together — taking care to disable RSTP or STP on the ports you have interconnected in creating the loop. Ping your subnet broadcast address. (For example, if your IP address is 192.168.1.1 and your netmask is 255.255.255.0, then your subnet broadcast address is 192.168.1.255.) This creates a traffic generator which can test your system survivability to various levels of traffic. Now you can adjust the amount of traffic being generated by the traffic generator. (Although some unmanaged switches offer broadcast storm control, a managed switch gives you the ability to control the level of traffic.)

Warning! Performing the above procedure on a production or office network will most likely cause communications problems — only a test network should be used.

Matching Fiber Optic Ports

It is surprising how often a question arises about determining the fiber optic port compatibility between two Industrial Ethernet devices. The issue frequently involves matching a media converter to a switching hub.

On several occasions I have been asked why existing equipment is not communicating through a newly installed media converter. The problem is usually that the fiber optic port of one device is incompatible with that of the other. It seems that installers tend to assume that because the copper port of the media converter auto-negotiates the data rate to either 10 Mbps or 100 Mbps, then the fiber optic port will also adjust automatically. But that is not so (except for seldom-used equipment that is compliant with the 100BASE-SX specification).

Industrial Ethernet hubs and switches that operate exclusively at 10 Mbps — and have at least one fiber optic port — will most likely comply with the 10BASE-FL specification for fiber communication (unless the equipment is very old). Most modern switches are capable of operating at either 10 Mbps or 100 Mbps — but although their copper ports may adjust for data rate, their fiber ports will comply only with the 100BASE-FX specification.

A fiber optic port will not negotiate its data rate because it is fixed at the rate specific to the transceiver type. A 10BASE-FL transceiver passes a 10 Mbps data stream using a fixed wavelength of 850 nm. On the other hand, a 100BASE-FX transceiver passes a 100 Mbps data stream at a wavelength of 1300 nm. If someone connects an 850 nm fiber optic port to a 1300 nm fiber optic port, communication will not occur due to this difference in wavelength.

Another, less-common, issue is the compatibility of the fiber optic cable itself.

Most multimode fiber optic cable in North America is 62.5-microns in diameter (elsewhere, 50-micron cable may be more popular). This cable is basically used for segment distances under 2 km, works efficiently at either 850 nm or 1300 nm, and uses LED transmitters.

Single-mode fiber optic cable has a tiny core diameter in the range of 5 to 10 microns, works efficently at either 1300 nm or 1550 nm, and uses laser transmitters. It allows much greater data flow and much greater distance.

Both multimode and single-mode fiber optic cable can pass data at 1300 nm. But even if passing the same wavelength of light, single-mode fiber optic cable, multimode fiber optic cable, and their respective transceivers are incompatible with each other.

When troubleshooting a problem in which newly installed equipment with fiber optic ports is not communicating, do this first: Confirm that the port characteristics at one end of a run of fiber optic cable matches the port characteristics at the other end!

The Value of Rate Limiting

On August 11, 2007, nearly 20,000 passengers (by some estimates) were stranded for many hours at Los Angeles International Airport. The incident involved a U.S. Customs computer network containing information used to screen passengers seeking entry to the United States. It went down around 1 p.m. PDT and was not restored until 11:45 p.m. The last of the backlogged travelers from some 73 flights were not processed for another five hours.

Acting port director Peter Gordon reported, "This is probably one of the worst days we've had. I've been with the agency for 30 years, and I've never seen the system go down and stay down for as long as it did". U.S. Customs and Border Protection spokesman Mike Fleming added, "This was unprecedented in terms of impact."

Early reports blamed a "computer glitch", then suggested faulty hardware in general and insufficient backup, then perhaps the fiber optic cabling. It was determined three days later to be a sputtering network interface adapter.

Whether the interface adapter was generating a broadcast storm or some other torrent of Ethernet frames is unclear, but there is no doubt that the system was derailed by the card's incessant output.

While this incident involved no loss of life (although many passengers were hospitalized), the inconvenience to the travelling public was monumental. In some areas of Industrial Ethernet, such an outage could prove very costly in terms of economics and lives threatened.

The lack of systems backup was bemoaned by several analysts, but providing backup is never complete nor perfect. With the use of rate limiting (or rate control) that is available on some managed switches such as those from Contemporary Controls, the problem could have been so minimized that the network would likely have survived the card failure.

The exact nature of rate limiting varies by equipment, but typically ingress and egress port traffic can be controlled for the rate and type of traffic. Switches with this functionality allow you to control the rate of broadcast, multicast or unicast messages — and perhaps even destination look-up failures and MAC control frames. With these tools, bandwidth allocation can be fine tuned.

By limiting all frame types, the full bandwidth of a port can be controlled. Selecting only broadcast frames will create broadcast storm control governed by an adjustable maximum bandwidth setting. Rate control can be useful for connecting a Windows® computer to the control network and for limiting communications from an unknown or uncontrolled network such as when interconnecting the office and control networks.

For more about the airport incident, follow the link below:

LA Times Article

Does Your Switch Block Certain Ports?

Some time ago, a customer called to ask, "Are ports 1628 and 1629 open or blocked in your Industrial Ethernet switch?"

In general, the question was referring to TCP/UDP ports — the numbering scheme by which OSI layer-four messages are identified and controlled. Note that TCP/UDP ports are mere numerical abstractions that serve record-keeping and permissions purposes. Such ports are altogether different from the physical ports where CAT5 cables attach to Industrial Ethernet switches.

This specific inquiry was about the LonTalk protocol which uses port 1628 for normal messaging and port 1629 for urgent messaging. TCP/UDP ports are identified by 16 bits and are therefore numbered from 0–65,535. The lowest-numbered ports (0–1023) are reserved for specific TCP/UDP functions. Ports 1024–49151 are reserved by organizations. The remaining ports up to 65535 are for private use.

Regarding the question posed by the customer, the simple answer was that neither these ports nor any others were blocked because our devices are layer-two switches. Layer-two switches are ignorant of TCP/UDP functionality. To selectively block such a port requires what is often called a layer-three switch (or a router).

In summary, if you are using a layer-two switch — whether plug-and-play, configurable or managed — you need not worry about it blocking any TCP/UDP port. A configurable or managed layer-two switch could impose blocking of a physical port, but it does not have the ability to block TCP/UDP ports.

Data Latency Can Be Variable

A recent inquirer was concerned that his measurement of data latency in Ethernet switches yielded widely varying results. He measured a latency of 7 microseconds (µs) in one test then twice that in a second test. Another device had a measured latency of 125 µs in one instance and 40 µs when measured again. The switches functioned well in all cases, but the inquirer was mystified by the differences.

The situation was that he was unaware of the profound variation in frame size that he was encountering. Latency measures the delay of the switch but also the re-transmission time of the frame. This means the longer the frame, the greater the delay. If the traffic with which you are concerned contains regularly-sized frames, you should expect very little variation in the data latency. But with random-sized frames, you get random latency.

An RSTP No-No

A while ago a customer complained of a very long recovery time (from one to four minutes) for his RSTP network. He had connected two managed switches (which had no fiber ports) through four unmanaged switches (RSTP-unaware) which he was using as media converters to provide a fiber backbone. The illustration below shows the six-switch network with the pertinent switch ports numbered. The RSTP protocol had forced the blue link inactive, making it the backup link. Then, to test his RSTP performance, the customer interrupted the red link — causing the blue backup link to activate. The fiber backbone is indicated by the green links. Analysis revealed that the unmanaged switch address tables were the source of the problem.

The RSTP protocol had elected MS 1 as the root device, placing its ports 2 and 6 in the forwarding state. On MS 2, port 6 was placed in the discarding state to stop messages from looping through the blue link.

Broadcasts affect the address tables of all switches. This is true even if a switch is not serving any message path — as is the case with UMS 3 and UMS 4 while the blue backup link is inactive. Consequently, UMS 3 and UMS 4 correctly register both PC 1 and PC 2 as connected on port 3 of each switch.

When the network topology is reconfigured due to an interruption of the red link, UMS 3 and UMS 4 become part of the communication path, but they will be ignorant of the reconfiguration. Consequently, UMS 3 and UMS 4 will still try to forward all messages to the left via port 3 of each switch — although the reconfiguration requires that messages from PC 1 to PC 2 exit UMS 3 and UMS 4 to the right via ports 4 of each switch. This means that once the blue backup link becomes active, messages destined for PC 2 will be lost until the address tables of UMS 3 and UMS 4 are corrected.

Switches filter, forward or flood received messages. They flood messages when the destination MAC address is not in their address table. They forward messages when the destination MAC address is in their address table. They filter messages (throw them away) when the destination MAC address is associated with the same port on which the messages arrive.

Message filtering was causing the problem for the customer. The solution was to use media converters (having no address tables) that pass link status between the managed switches.

It is unwise for your RSTP network to have a mix of switches that are RSTP-aware with those which are RSTP-unaware. As can be seen in this example, sometimes the effects of such mixing can be impair network performance.

No Minimum Length for CAT 5

Various networking technologies specify that stations must be separated by some minimum distance. Occasionally a customer is surprised about the lack of a minimum length requirement for their CAT 5 cable that connects one Industrial Ethernet device to another.

Network cable minimum length specifications arise because of an impedance mismatch between elements in the signal path. When electrical energy is transmitted through a cable, some of it is not absorbed by the receiving station and is instead "reflected" back to the source. This reflected energy disturbs the purity of the signal — and if the effect is of sufficient magnitude, the signal can be degraded to the extent that its information is corrupted or even useless. If source and destination transceiver impedances match the impedance of the cable itself, there is no reflected energy and signal energy is delivered completely.

Reflected signal is always an issue in a bus topology because only the end devices have transceiver impedance values that match the impedance of the cable. Mid-bus device transceivers must have higher impedance values to avoid "loading" the cable (preventing proper signal delivery to devices further along the bus). Thus, a mid-bus device transceiver presents an impedance mismatch to the cable and inevitably creates some degree of reflected energy. To keep the reflected energy to acceptable levels, a bus protocol will specify a minimum length of cable that separates two bus devices.

Industrial Ethernet uses a star topology in which devices exist only at each end of a cable. With this topology, both transceiver impedances match the cable impedance and no appreciable signal reflection occurs. This lack of signal reflection is true whether the devices are separated by 100 m or 100 mm. Therefore, there is no need to specify a minimum cable length.

Wire-Speed Industrial Ethernet

When asked if an Industrial Ethernet switch from Contemporary Controls is a wire-speed device, I reply that all of our switches are. But what does wire-speed mean?

Wire-speed operation means that a switching hub port will pass traffic at its specified rate regardless of how much activity may be occurring in the switch as a whole. A repeating hub cannot achieve wire-speed because it cannot provide the simultaneous data exchanges that occur within a switch.

To achieve wire-speed, the internal fabric of a switch must be capable of processing data at a rate no less than the specified data rate multiplied by the number of ports in the switch. For example, if a 100 Mbps switch has eight ports, its backplane circuitry must be able to process data at a rate of at least 800 Mbps. Some manufacturers imply this but state it in another way, claiming (for example) that their 12-port 100 Mbps switch has a 1.2 Gbps capability (12 ports x 100 Mbps per port).

Vendors typically claim their switches can sustain layer-2 wire-speed forwarding without frame loss. To properly comply with wire-speed switching, address lookup should be done while the IP packet is moved from the input port to the output port without buffering. To confirm that a switch is operating at true wire-speed, elaborate throughput testing is required. Typical tests disable features that transcend basic layer-2 functionality such as throughput limits, flood limits and VLAN port tagging.

Regardless of wire-speed assurances, switch performance in practical situations can depend less on data throughput and more on such features as QoS, IGMP snooping or VLANs. The need for true wire-speed operation is seldom an issue in building automation or industrial settings and is mainly of concern in applications that require intense packet-switching such as video security systems.

What Is MTBF and What Good Is It?

From time to time, a caller asks me about the MTBF rating of one of our devices. The abbreviation MTBF stands for

Mean-Time-Between-Failure

and indicates the reliability of the specified equipment. It is the typical time between failures for a specified device design — that is, the typical amount of time (in hours) any of a specified set of devices will function before failing.

However, different companies define failure in different ways, depending on the nature of the equipment and its function within a system. Also, test parameters and batch size are not standardized. Essentially, higher MTBF ratings for finished goods are obtained by building equipment with components that have high individual MTBF values — that is, better quality components.

MTBF grew out of the US military's attempts to formalize reliability assessment in the 1950s and 1960s which resulted in the publication of MIL-HDBK-217. Various flaws with this document led to a number of revisions and eventually, "... the U.S. Army has discovered that the problems with the traditional reliability prediction techniques are enormous and have canceled the use of MIL-HDBK-217 in Army specifications ..." Source: Equipment Reliability Institute's "ERI News", August, 2001 — vol. 4.

Despite criticisms of MTBF (especially within MIL-HDBK-217), it remains the dominant reliability assessment tool in the commercial electronics industry. The "Telcordia SR-332" handbook is used by many non-military electronic manufacturers for generating MTBF values. It evolved as follows: In the early 1980s Bellcore (Bell Communications Research) spun off from AT&T Bell Labs. Starting in 1985, Bellcore used MIL-HDBK-217, then improved and adapted it for highly-integrated commercial electronic products. In 1997 Bellcore was sold and its name was later changed to Telcordia Technologies.

At Contemporary Controls, equipment reliability is specified by MTBF values produced through the use of the Telcordia standard: Method I — Case I — Quality Level I.

Although the derivation of an MTBF value can be mathematically quite involved, the process can be generally stated as:

(Total Operating Time) / (Sample Size)

Suppose, as a very simple example, we test five electronic components until each one fails with the following results:

After totaling the above hour counts (3000), we would divide by the sample size (5) to get an MTBF for the component:

MTBF = 3000/5 = 600 hours

The above MTBF example means that we would expect the theoretically typical component to fail after 600 hours of operation. Stated differently, if we assume that all five components were typical, we would expect all of them to fail at 600 hours, with an average failure rate of one every 120 hours (600/5). Note that every component greatly outlived the 120-hour statistical failure mark for an individual. The 1-failure-per-120-hours is merely a statistical artifact that only achieves significance once the group size becomes much larger than in this example.

Actual MTBF values are much, much higher than the preceding example. Indeed, some exceed 1,000,000 hours! Industrial Ethernet switches usually have MTBF ratings of about 500,000 hours. That is, of all such units tested, the typical one would fail at 500,000 hours — also, all of them would fail at 500,000 hours, if the entire group is composed of typical devices. Of course, no one really tests devices for such a long time — 500,000 hours is about 57 years! Actual MTBF ratings are either: projections based on a record of actual product failures, or predictions made by aggregating known MTBF values from component or sub-assembly suppliers.

Some people like to look at the MTBF like this: If a group of 1000 Industrial Ethernet switches has an MTBF rating of 500,000 hours, we could expect all 1000 units to fail within some 57 years. But if all 1000 were placed in service over the same time period with an evenly-spread failure rate, we could statistically expect one to fail about every 21 days, based on the following calculations:

MTBF / population size = mean unit time to failure

(500,000 hours) / (1000 switches) = 500 hours mean lifetime per unit

(500 hours) / (24 hours in day) = 20.83 days

However, the foregoing result is very misleading. Firstly, assuming a symmetrically balanced failure record, the odds are 999 to 1 that a particular switch will fail after 21 days! Also, various factors (some unknown) skew the typical failure model toward the MTBF value. That is, in reality the 1000 switches tend to fail (or wear out) at roughly the same time (near the MTBF value). But the averaging process yields a statistical result that predicts one failure every 21 days — even though the true lifetime of the vast majority of switches is much nearer the MTBF.

From this you can see that an MTBF rating is of no value when applied to an individual item (nobody replaces a device every 21 days). Instead, the MTBF is a figure-of-merit that predicts the reliability of an entire group of products. What we should care about is: The greater the MTBF of the group, the more reliable a typical individual product within the group!

Niagara Summit 2006 in Florida

The 2006 Tridium Niagara Summit took place from April 30–May 2 at the Saddlebrook Resort in Wesley Chapel, Florida (just north of Tampa). Two Contemporary Controls staff attended: R & D Manager Bennet Levine (in the lower photo) and Sales Manager Joe Stasiek. There were 415 attendees at the summit (compared with 320 in 2004), most of whom were system integrators and developers.

Monday afternoon, Mr. Levine addressed the Complimentary Technologies Session, speaking on networking equipment designed for the rigors of automation applications.

Keynote speeches included Strategies for Smart Services by Glen Allmendinger, Founder and President of Harbor Research; and "Co-opertition" — A Unique Blend of Cooperation and Competition by Ramon Casadesus-Masanell, Assistant Professor, Harvard Business School.

Contemporary Controls (one of over 30 exhibitors) unveiled its latest Industrial Ethernet product — the BAS Remote I/O which offers six universal I/O points and two relay outputs. There was also much interest in the company's recently announced EtherNet/IP switches that feature IGMP Snooping.