Murphy’s Law of Industrial Networking
This rule of thumb says that as soon as you complete eight months of Foundation Fieldbus development, your first major customer will ask for Profibus PA. Lost opportunities are inevitable unless you can find a way to support more than one network without multiple lengthy development cycles. There are few industrial or data acquisition products that can function with only one network and still satisfy 90% of the customers. In some cases, Ethernet alone is sufficient, but that’s not the norm.

So what’s the best approach? Volume, time to market, and price determine the answer to that question (see Table 1).

TABLE 1
Tradeoffs in the Development of Network-Enabled Sensors
Highest per-unit cost Fastest time to market Lowest up-front cost			Lowest per-unit cost Longest time to market Highest up-front cost
Qty. = 10's	Qty. = 100's	Qty. = 1000's to 250,000	Qty. = 250,000+
Gateway on PC Interface	Daughterboard	Integrated network controller, Hybrid IC or System-on-a-Chip	Discrete components

One approach is to use a gateway. These devices are black-box solutions that are expensive but quickly implemented. Usually, they’re used to solve an urgent problem on a specific installation. Plug-in modules are ideal for small-to-medium volume applications (i.e., hundreds of units per year) and can be quickly implemented. A chip-based solution may require the most up-front integration, but for high-volume jobs, the cost savings are dramatic.

PC Interfaces

Photo 1. On this PCI Profibus card, the upper left DB9 connector is the Profibus connector, and the lower left DB9 connector is the serial port, which can be used for diagnostics and configuration when the card is used in a non-Windows PC. All functions of the Profibus protocol are handled in real time by an onboard 186 processor. (Courtesy of Synergetic Micro Systems, Inc.) Photo 2. This 2-channel PCI CAN card is an interesting example of the single processor-coprocessor tradeoff. There is no microprocessor on this card, only a PCI interface to a pair of CAN controllers. High-level applications (e.g., J1939, DeviceNet, or CANOpen) must run on the PC's host processor, sharing bandwidth with other applications running on the PC. This approach invites data consistency problems in a multi-tasking operating system (e.g., Windows), but it can be an economical approach for some applications. (Courtesy of Peak Systems.)

If your product is PC based, then the quickest and easiest way to connect it to a network is to use a PC card (e.g., a PCI or PC/104). These devices are available from many vendors for nearly every imaginable network (see Photos 1 and 2), and normally thmir documentation describes how process data can be exchanged between the card and the application software.

If you decide to use a PC card, your first task will be to find an application program interface, or API. If the card has a driver for the operating system you’re using, then you can write programs in C or C++ and access the network via function calls.

One of the unfortunate aspects of software interfaces is the need to constantly write new drivers to support the growing list of hardware components. If you’re about to write software to interface to a network card, be sure to think about which networks you plan to support.

One Common Interface for All Buses?
The multiple fieldbus scenario gets really ugly if you’re a device manufacturer or OEM who’s trying to support all these buses. How do you interface a control program or field device to multiple fieldbuses without spending years writing code? How do you find a common denominator for all these buses?

This is a thorny problem for OEMs. Nobody—not even large, influential vendors—can count on all their customers using one bus. For any given application, there are at least three major networking standards that could do a good job.

One solution is to define a common API, which reduces all the disparate communications mechanisms to a common memory map and a set of function calls. You can apply a common interface to all buses, capitalizing on the similarities between the bus structures (see Table 2).

TABLE 2
Similarities Between Bus Structures
Outputs	Inputs	Messages Sent	Messages Received
(Periodic and event driven)	(Periodic and event driven)	(Master/slave and peer to peer; configuration writes for all parameters)	(Master/slave and peer to peer; configuration queries for all parameters)

There’s an 80/20 rule that comes to the developer’s advantage here. Typically, 80% of the information used by an automation system is basic, synchronous I/O data, and this is handled the same way by all buses. Once you’ve written code for I/O, you essentially have support of all the buses.

The other 20% of the data—the configuration, parameter, and diagnostic data—are where you find the “value added” portion of a network. It’s not needed to make the system run. But if you take the time and use the information with care, it’s where substantial productivity, multiplied value, and maintenance advantages come in. It may take a lot of additional work, but it’s well worth the trouble.

The trick is to come up with a method that makes the information available without spending six months writing custom code for every fieldbus you wish to support. A common API helps this tremendously. For example, the Synergetic/Hilscher family of network cards uses a single Dual Port Memory map. Once the data exchange software is written for one network, it can communicate to other networks with minimal changes. The expense of rewriting software is drastically reduced.

Generic and Industry-Standard Software Interfaces
Object linking and embedding for Process Control (OPC) is a software interface backed by Microsoft and many automation vendors that provides a link between hardware and software. Any software with an OPC client can talk to hardware with an OPC server because they both support OPC.

Dynamic Data Exchange (DDE) is an older technology that was designed with the same thing in mind. It’s not as fast as OPC, but it is common in the software world. For example, you can use a DDE server to put live data in an Excel spreadsheet.

Gateways—A Quick and Dirty Way to Connect
A gateway converts data from one network’s format to another’s. These devices are expensive and a bit kludgy, but they can get you out of a jam.

Many times a customer must connect a device (e.g., a barcode reader, drive, or temperature controller) to a fieldbus, and the device has only an RS-232 or RS-485 port. Is there a solution? A serial-to-fieldbus gateway provides instant connectivity, giving you time to implement a more permanent link. Protocol converters usually include a configuration utility that establishes communication parameters and maps one side to the other (see Figure 1).

Figure 1. Using a fieldbus-serial gateway, a device (e.g., a temperature controller or moisture sensor) can be linked via a serial port to another industrial network.

Photo 3. This protocol converter links RS-485 to Profibus. The serial channel uses the Modbus protocol, and the device converts Modbus registers to Profibus I/O. A software utility maps these registers. The gateway links serial devices (Modbus on RS-232, RS-422, or RS-485) to Profibus, enabling non-Profibus devices with just a serial port to communicate with a Profibus network.

The serial device can communicate using Modbus or another common serial protocol (see Photo 3). Using RS-485, you can multidrop as many as 31 devices on the serial side. Devices are mapped into a single slave node on the fieldbus network.

“Which Network Do I Do First?”
The quickest answer to this question is, Implement Modbus RTU/ASCII, and use a gateway to link to the other network. You can have this solution up and running in hours, not days or weeks. Why Modbus? It’s probably the most widely supported industrial network. Modbus on industrial equipment is like cassette players in cars. Its performance isn’t great, and nobody’s bragging about it, but it’s out there. The advantage is that it’s easy to implement, and you can move data from Modbus to just about any other network using a gateway.

Band-Aids vs. Permanent Solutions
You sell 5000 sensors a year, but only 2000 are sold with network connectivity. You predict with reasonable certainty that 500 units will use Ethernet, but the other 1500 units are divided unevenly and unpredictably among six other network protocols. One customer may buy 50 ControlNet units, but there’s no way you can justify the development cost just to sell 50 units. If you had to do it yourself, you’d have to turn the customer away.

One solution is to use snap-in communications daughter boards. This approach works for small-volume applications, but a chip-based solution makes sense for larger, high-volume applications.

These modules allow device manufacturers to enable their products with the ability to communicate via multiple protocols (master or slave in most cases) simply by snapping in a customized daughter board. The boards usually have the same footprint and software interface. Certification and conformance requirements and core network expertise can be effectively outsourced to a network vendor.

Putting the footprint in your product ensures that you can meet the networking needs regardless of the protocol required. And modular solutions are especially helpful where the exact demand for the network protocol is unknown.

Licensing Designs
Another approach to embedding, low-cost network connectivity involves licensing a hardware design and/or source code. You can do this either on a separate communications board with its own processor or on a mother board integrated into the product itself.

Once again, the issue of single network vs. multiple network capability comes up. If the volume of some options is low, fall back on the off-the-shelf OEM daughter board I mentioned earlier. But for high-volume applications, an outsourced design is a gr±at option. The up-front cost can be in the thousands or tens of thousands of dollars per network, but from that point on, it’s purely a matter of manufacturing considerations.

There are many networking specialists who can provide off-the-shelf designs and customization services. If you make flow sensors, it’s probably best to keep your staff focused on the core product design and outsource communications to consultants. Ultimaüely, this path is less expensive, takes less time, and results in a higher quality product, which passes testing and conformance certification faster. Plus, if you encounter a difficult field application (did someone say “finger-pointing contest”?) you have an expert to fall back on.

System on a Chip
An emerging product category is multinetwork chips. One of the first entries in this market was Synergetic’s EmbeddedComm EC-1, which combines Ethernet 10/100, 2 CAN channels, 2 Serial channels, SPI, Dual Port Memory, an x86 microprocessor, and RAM in a üingle 144-pin chip. Designed for applications numbering in the thousands and tens of thousands of units, where multiple types of networks are required within the same product family, it enables manufacturers to produce a single PCB and populate it with the necessary transceivers and peripheral components in production. You can use the chip as either a stand-alone processor, running the entire application, or as a coprocessor with a common software interface for all networks.

Integrated Chip Solutions
The next level of cost reduction for high-volume products is achieved by combining a single network interface with a processor and some peripherals. Where the economics of a design and quantity justify a PC board dedicated to a single network, this is an excellent solution. Motorola and NetSilicon offer microprocessors combined with Ethernet; Philips, Siemens, and others combine CAN with a microprocessor. For example, the Siemens SAF-C505 combines an 8-bit microprocessor with 32 KB of ROM, 1 KB of RAM, and a full CAN controller. You can implement small CAN applications (e.g., interfaces for digital I/O) at low cost with this device.