Newspaperman Malcolm Muggeridge once said, "News is old things happening to new people." New technologies always have their allure, but after three decades of networks, it's no secret: Today's innovations are usually just rehashed formulas from years gone by. Or as one of my friends says, "If you want a new idea, read an old book."

So after 20 years of Arcnet, Bacnet, DeviceNet, CAN, Ethernet, Modbus, and a dozen other networks, what's really new? And what's really just old hat?

I was discussing $1,000 network cards (i.e., for Profibus, Modbus Plus, and remote I/O) with an information technology (IT) specialist who was unfamiliar with the automation biz.

The IT guy said, "To an engineer, anyone who is talking about $1,500 PC cards in today's market of under $10 connectivity is talking dark ages."

Of course, it was news to him that Ethernet as a fieldbus alternative wasn't even discussed much until about four years ago, and $1,000 network cards are still common and often justified. But he's right—Ethernet's been around since the mid-1970s and the same with TCP/IP.

RS-485 is older than dirt, and CAN has been in luxury vehicles since Madonna was an up-and-coming Material Girl. And though Arcnet doesn't get much front page news these days, it's been under the hood in all kinds of systems since the late '70s and called by various names, especially in building automation.

The story of Arcnet is one that has undoubtedly repeated itself millions of time in human history. In this case, a motley team of engineers and support people was faced with the unique challenge of creating the world's first computer network.

But at the same time, they really had no idea what they had done. They had no basis for comparison.

It took years for history to prove their architecture was superior. In fact, it's funny to observe that virtually every key component, such as active hubs, was created for Arcnet and has since been adopted by other, more popular networks such as Ethernet.

So what do the past 20 years teach us? In my opinion, three lessons stand out:

• Being there first is not for the faint of heart, for many pioneers shall return with arrows in their backs.
• Openness is superior. It greatly expands the market and reduces risk.
• Nothing sells itself, so never underestimate the importance of marketing and sales.

John Murphy, Datapoint engineer and chief architect of Arcnet, said, "The term network was the last thing in the world we wanted our customers to associate with this."

The term had an image problem: It evoked images of behemoth systems that were complex and hard to mange. The word LAN was not yet in use, and some people doubted large numbers of computers would ever need to talk to one another anyway.

But the technology really was reliable, so much so that you could literally run it across barbed wire.

Early training classes used untwisted coat hangers. And today, even though networking may be bleeding edge for some folks, the technology is very mature and well established.

And because most people reading this magazine are in various aspects of instrumentation and automation, the world of heating, ventilation, and air conditioning (HVAC), security, and building automation has some definite parallels.

Bacnet doesn't attract much attention in automation circles, but it's instructive in the current Ethernet free-for-all. It's a data communication protocol for building automation and control networks. It's in many thousands of buildings—perhaps the one you're in right now—controlling HVAC and security systems.

Bacnet can exist on five physical layers, including Ethernet, Arcnet, Lontalk, point to point, and MS/TP. Existing protocols repackage a new physical layer onto an existing data link layer in the vein of Ethernet automation protocols such as Modbus/TCP, EtherNet/IP, and Profinet.

It's the same story with CAN. CAN was developed for automobiles, and a number of vehicle protocols are in use, both open and proprietary. J1939 is popular in trucks and buses, and DeviceNet and CANopen are popular in automation equipment.

CAN is based on broadcast communication. Rather than defining stations and station addresses, it defines a message. Unique message identifiers label messages defining both the content and the priority of the message.

It is very easy to add stations to an existing CAN network without making any hardware or software modifications to the existing stations, as long as the new stations serve only as receivers.

The electronics become modular, and data needed by multiple stations can transmit such that it is not essential for each station to know who produced the data.

CAN differs from the other major networks in that all devices on the network operate in lockstep synchronization. This allows competing devices to arbitrate without retransmitting or losing packets. The price paid for this transmission efficiency is a restriction on network length.

Remember how I said nothing sells itself but must be successfully marketed as well? Well, there are a number of hot networking buzzwords you need to use if you want to gain acceptance: peer to peer, robust, redundant, Internet and TCP/IP compatible, wireless, Bluetooth, 802.11, Wi-Fi, deterministic, real time, and streaming media.

So it's really quite easy to create a new networking technology. You just mix and match old networking protocols and encoding mechanisms (TCP/IP, Modbus, Manchester, or NRZ) and physical layers (EIA RS-485, Ethernet, CAN, or Arcnet), and stick as many of those cool buzzwords in your press release as you can.

You might think I'm joking, but really I'm quite serious. Not that anybody's going to do a $100 million initial public offering based on some new kind of industrial network, but there are certainly specialized machine and process control requirements that warrant something slightly different than what's already popular and widely available.

The good news is, you don't have to look far. There are free application guides for any of these networks. The folks at Contemporary Controls have a white paper, "10 Issues to Consider Before Installing Industrial Ethernet," as well as an Arcnet tutorial (Yes, people are still designing in new Arcnet networks after all these years . . . InTech@ccontrols.com for guides).

Microsoft's .NET strategy is a battle of e-commerce protocols and programming languages, all functioning with, or on top of, TCP/IP. The functionality of protocols increasingly extends beyond the physical medium itself, and in the commercial world it's a battle of protocols instead of networks.

The same is the case in industry. Industrial Ethernet is clearly a winner, but the alphabet soup of Modbus/TCP, EtherNet/IP, Foundation fieldbus HSE, and Profinet is where the battle lines are drawn.

Will all these protocols converge as devices are designed to support multiple protocols at the same time? Well, yes and no. Yes in the sense that this is possible. No, based on the historical precedent that major players are always searching for ways to include proprietary components.

Take Microsoft .NET, for example—a clever mix of open and proprietary elements. So caveat emptor: Make sure your vendor can demonstrate interoperability before you buy. IT