A Comprehensive Guide to
Industrial Networks

Part 2: Embedded Networking 101 – The Nuts and Bolts of Hardware and Software Design

Perry Sink Marshall


The world of computing was turned upside down by networks and the Internet. Today, a new force is redefining the sensor””embedded network capability. But to successfully join the move to sensor connectivity, you have to come to grips with a plethora of network protocols. Part 1 of this series described popular industrial networks and looked at some less common but important protocols. It also showed how a traditional mass flow controller that generates seven performance variables compares with the DeviceNet version, which provides more than 200 parameters. The implications are powerful: Networked sensors offer more value because they deliver information that was beyond the reach of yesterday’s technology.

Once you’re sold on the idea of networking your sensors, the next step is to find out how you can add high-performance networking to your design. To begin, you’ll have to answer some questions about design and basic hardware requirements. What data structure is used, and who defines it? Should you use a single processor or a coprocessor for the network software? Are ASICs necessary? What functions should be performed in hardware and which should be handled by software? What kinds of software development tools are necessary? And what are the certification and support requirements?

Layers of Information

Everything associated with networks””or any kind of digital information, for that matter””is done in layers. You can create a Microsoft Word file that combines text; tables; and TIFF, GIF, and JPEG files. You might encapsulate it in a ZIP file and then encode it with Pretty Good Privacy (PGP) encryption software. You attach it to an e-mail message using the MIME format and send it to me via a 56K modem. The e-mail is encoded in an analog signal by the modem and transported via the TCP/IP suite of protocols. The message is stored on my e-mail server, and when I receive the message, I unwrap six levels of encapsulation””TCP/IP, MIME, PGP, ZIP, .DOC, and the graphics inside the document. And in fact, TCP/IP is not just a single layer; it’s actually five layers, making a grand total of 11 layers. The layering of information breaks the process down into manageable pieces and simplifies a complex mechanism.

Now, you can’t talk about networking and layers of information without mentioning the ISO/OSI model. And when you do that, someone is bound to say, “Would somebody please explain this seven-layer networking model?” For many years, this model has been used as a way of representing the layers of information in a network, particularly the low-level transport mechanisms. From top to bottom, let’s look at these layers and see how they relate to your product design (see Table 1).

The ISO/OSI Networking Model
Layer 7 Application Defining the meaning of data
Layer 6 Presentation Building blocks of data and performing encryption
Layer 5 Session Opening and closing communication paths
Layer 4 Transport Error checking
Layer 3 Network Determining data paths in the network
Layer 2 Data link Managing data transmission, source, destination, and checksum
Layer 1 Physical Defining voltage levels and signal connections
Layer 0 Transmission Defining physical data transport (e.g., copper, fiber, wireless media)

Most networks don’t actually use all these layers. For example, Ethernet and RS-232 are just physical layers. So RS-232 uses only layer 1, and the Ethernet specification contains only layers 1 and 2. TCP/IP is a protocol, not a network, and it uses layers 3 and 4, regardless of whether layers 1 and 2 are a phone line, a wireless connection, or a 10Base-T Ethernet cable. It might be helpful to look at each layer and see how it fits into the big picture.

Layer 7 – Application.

This layer defines the meaning of the data itself. If you send me a PDF file via e-mail, the application used to open it is Adobe Acrobat. Many layers of protocols are involved, but the application is the final step in making the information usable.

In a sensor design, this is the software component that exchanges process data between the sensor elements (and their A/D converters) and the communications processor. The software recognizes the meaning of analog and digital values, parameters, and strings.

J1939 and CANOpen are application layers on top of CAN. Foundation Fieldbus HSE is an application layer on top of Ethernet and TCP/IP. And Modbus is an application layer on top of RS-232/-485.

Layer 6 – Presentation.

The presentation layer converts local data into a designated form for sending and converting received data to the local representation. It might convert a character set such as MacRoman to ASCII for transmission. Encryption can also happen in this layer. Layer 6 is usually handled by application software and is not often used in industrial networks.

Layer 5 – Session.

This layer creates and maintains communication channels (sessions). Security and logging can be managed here. Layer 5 is handled by software and is not commonly used in industrial networks.

Layer 4 – Transport.

The transport layer controls transmission by ensuring end-to-end data integrity and by establishing the message structure protocol. It performs error checking. Layer 4 is usually handled in software (e.g., TCP/IP).

Layer 3 – Network.

The network layer routes data from node to node in the net²ork by opening and maintaining an appropriate path. It may also split large messages into smaller packets to be reassembled at the receiving end. Layer 3 is handled in software.

Layer 2 – Data Link.

This layer handles the physical transmission of data between nodes. A packet of data (a data frame) has a checksum, a source, and a destination. This layer establishes the physical connection between the local machine and the destination using the interface particular to the local machine. Layer 2 is almost always handled by hardware with ASICs, but low-speed networks can perform layer 2 functions in software.

Layer 1 – Physical.

The physical layer defines signal voltages and physical connections for sending bits across a physical media. This includes opto isolation, hubs, and repeaters.

Layer 0 – Physical Transmission Media.

This refers to the tangible physical medium that transports a signal, whether it’s copper wire, fiber, or wireless technology.

The data to be transferred starts in the application layer and moves down the seven layers to the physical layer, where it is sent to the receiving system. At that end, it’s passed up through the layers to the remote application layer, where it’s received by the user. Most protocols are related to the ISO/OSI model, but they don’t follow the exact specification. Instead, they combine different layers as necessary.

A Single Processor or A Coprocessor?

One of the first questions to ask is whether you want to use your existing microprocessor for network firmware or add a second processor to handle the network communications (see Figure 1 and Figure 2).


Figure 1. This diagram shows a product that uses a single microprocessor and a network interface. The processor handles all tasks and allocates a percentage of bandwidth to communication. This is the least expensive way of adding communications to a design, but the implementation can be messy.


Figure 2. Coprocessor-based communications design separates microprocessors for product functionality and network interface. Coprocessor designs are more expensive, but they’re more modular, flexible, and robust.

The pros and cons are listed in Table 2.

Single vs. Dual Processor Product Design
Single Processor •Lower cost •Lower parts count •One software application to write •One binary file •Less physical space required •Must handle real-time network traffic with room to spare under all conditions •A burdened microprocessor may not be able to keep up •Product functions and network functions run simultaneously in the same environment
Coprocessor •Minimal burden on main processor •Modular hardware and software •Easy support of multiple networks •Higher cost •Double parts count •Double physical space •More memory

How does the network hardware interface with the rest of the product? In the case of a single processor, the network ASICs must communicate with the processor via shared memory or a serial port. With a coprocessor, there are many possibilities. Dual Port Memory is common, as are serial ports, I2C, and Serial Peripheral Interface.

Why Are ASICs Necessary in Communications Designs?

“Can’t I just use a microprocessor instead of taking on the additional cost of an ASIC?” you ask. Network ASICs cost anywhere from under $1 to more than $50 each. In some cases, the cost of the ASIC is the greatest determining factor in the economics of the design. So it’s reasonable to ask whether the ASIC is really necessary.

Any software function can be performed by dedicated hardware and vice versa. But there’s a tradeoff of economics and performance. A microprocessor has to process the incoming signal and calculate checksums and parity one bit at a time. Handling these tasks for even a single byte can consume dozens of clock cycles. Alternately, a Universal Asynchronous Receiver Transmitter (UART), an ASIC, or a dedicated network controller uses state logic to process a byte or more of data in a single step and presents only the useful data to the microprocessor.

A hardware design with predefined gates and intrinsic logical functions is fast, but it can add significant cost. Generic hardware (i.e., a simple processor with memory) that uses software to perform functions is orders of magnitude slower. In high volume, the microprocessor approach can be less expensive.

Profibus can be implemented either way, with speeds ranging from 9600 bps to 12 Mbps, using RS-485 as the physical layer. With appropriate software, low speeds can be achieved using any serial port, and the processor can respond to every changing bit as it comes in.

But as speed goes up, the demands on the processor grow. You might be able to implement a Profibus design that runs at 500 Kbps without an ASIC, but beyond that point, it is less expensive at $20-$30 per unit to use the ASPC2 (master) or SPC3 (slave). Perhaps a Pentium III processor could keep up at 12 Mbps, but it wouldn’t be cost effective. Table 3 details some of the most commonly used communications chips for networks.

Network-Specific Hardware Components
Network Common ASIC(s)
Modbus RTU/ASCII None
CAN-based networks (e.g., DeviceNet, CANOpen, J1939) SJA1000, 82C251, and others
Profibus DP & PA Multiple ASICs, from Siemens and Profichip
Ethernet, Web server, Industrial Ethernet, Foundation Fieldbus, HSE AM79C960 is most popular; many others
LonWorks Toshiba Neuron Chip
HART Cybermetic P51
Interbus Phoenix Contact IPMS (master), SmPI II (slave)
Foundation Fieldbus H1 SMAR FB3050
Arcnet Multiple chips from Standard Micro Systems Corp.
Sercos ST Microelectronics SERCON410B
ControlNet Rockwell CNA 10 ControlNet ASIC

Voltage Isolation

You don’t need a Van DeGraf generator to damage electronic devices. Any communications chip, particularly in an industrial environment, is vulnerable to damage from voltage surges. Conductors can be affected by various voltage sources””ungrounded equipment, static electricity, noise induced from motors and drives, RF energy, and mistakes in installation. An inductive circuit that is suddenly disconnected from current flow can generate thousands of volts for a few milliseconds. Discharged static electricity produces a similar effect. These surges can wipe out transistor junctions instantaneously.

Active components must be isolated from electrical disturbances. Because every device on a network uses active components, every node on the network needs voltage isolation. Typically, you achieve this with optoisolators or transformers. These guarantee varying degrees of protection, typically 500 VDC (a normal 120 VAC line produces 380 V peak to peak). The goal is to avoid current flow created by potential differences between ground points. Higher voltage ratings require larger components with greater spacing between active elements. Circuit board layout also becomes more important as ratings go up. The circuit shown in Figure 3 is used to buffer a CAN controller.


Figure 3. Shown here is a CAN interface circuit, including (from left to right) the transmit-and-receive terminals to the network cable; optoisolators, which protect circuitry from voltage spikes; a transceiver, which boosts current levels; and the connections to the low-current CAN controller. There’s no particular significance to the choice of CAN for this example. Other networks use similar transmission circuitry for similar reasons. Ethernet interfaces make two substitutions. The transceiver is replaced by a PHY, which not only performs electrical buffering but data buffering as well. And the optical isolators are replaced by transformers, which perform essentially the same function.

Master vs. Slave Definitions

In the context of a control system, a master, or server p reads inputs, writes outputs, requests information from other devices, and solves logic. On the other hand, a slave, or client, provides information to the system and usually speaks when spoken to. Peer-to-peer capability is possible on many networks, but it’s not frequently used.

When linked to a network, most sensors will be slaves, not masters. But if your sensor is programmable and plays a central role in a larger system, it’s worthwhile to consider how master capability could redefine the sensor and save your customer the cost of an extra controller.

A simple example of this idea is a programmable limit switch (PLS), which switches outputs on and off at predefined points as its shaft rotates. Often a PLS is used in an automation system controlled by a PLC, but in simple packaging machines, the PLS controls the entire machine by itself.

A PLS can control a simple machine even if it has no network connection, but it can control a large, complex machine if it has master capability. Could your sensor not only monitor a process but control a system? If so, you’ve got a good reason to make your sensor a master, not just a slave.

Master vs. Slave Complexity

A slave device holds a number of configuration parameters and makes information available to the master. But usually the master sets the parameters (see Table 4).

Master vs. Slave Parameters for a Profibus Network
Master Parameters Slave Parameters
•Host (PC application software) control vs. device (Profibus card) control of data exchange •Watchdog timer •Big Endian/Little Endian byte configuration •Process data handshaking and consistency •Master node number •Number of bytes in/bytes out •Assigned master node number •Alarm message management •Autoclear function •Hex address for accessing data in shared memory •Tag names •Slaves node number

A master must have a database of configuration parameters (all of which must match the configuration of the slaves) and manage all traffic on the network without interoperability problems. This means that a master is ten times more complex than a slave. Its firmware must support all the basic communications tasks, and it must also have a software tool that makes configuration as straightforward as possible. But these tools make it more expensive to design a master than a slave. Configuration software also maps the data on the network to the application software program (see Screen 1).


Screen 1. What you see is a Profibus network. The master is in the upper left, and the slave devices are below. In this example, the configuration tool, Hilscher’s SyCon, sets such parameters as node numbers, baud rates, size of packets, timeouts, and messaging types.

What Do Configuration Tools Do?

Network configuration tools establish the relationships between the master and the field devices””node numbers, message size, message scheduling, timeouts, parameters, you name it. They store these parameters in databases, which can later be modified as necessary. Normally, a configuration tool performs diagnostic functions and can manually manipulate data on the network.

SyCon is a software package that configures AS-I, CANOpen, ControlNet, DeviceNet, Interbus, and Profibus, using the same look and feel for all networks (see Screen 1). The complexity of the configuration tool is a major reason why developing a master is so much more involved than developing a slave.

What Is a Typical Development Schedule?

The complexity varies from network to network. Modbus is pretty simple, and it can be implemented on a serial port in a matter of days or weeks. This is one of the reasons I recommend having the Modbus protocol on your RS-232, -422, or -485 connection.

But if you’re working on DeviceNet, Profibus, or Foundation Fieldbus, you can spend one month completing the hardware design of a slave (not a master) network implementation; two months developing firmware; three months testing, debugging, and finishing the design; one month obtaining certification; and three months writing documentation and informing marketing and sales of the new capabilities. This is 10 months of dedicated effort per network (see Table 5).

Timeline for Development of Slave Devices
Hardware design Firmware development Test and debug Certification Documentation and sales issues
1 month 2 months 3 months 1 month 3 months

Developing an Ethernet implementation and master capabilities is even more involved and time consuming (see Table 6).

Timeline for Development of Master Devices
Hardware design Firmware development Configuration software Test and debug Certification Documentation and sales issues
1 month 9 months 6 months 6 months 2 months 4 months

At a typical engineering cost of $10,000 per worker month, you end up investing $100,000 per network in engineering and product management expenses. This must be amortized into the cost of the product.

What Interoperability Issues Can You Expect?

Interoperability is one of the “gotchas” that you have to plan for. Anyone who’s ever installed a network knows the difference between how things should work and how things do work. Devices that should talk to each other often don’t.

There are some typical problems that you’ll run into no matter how experienced you are in dealing with networks. For instance, the fact that there are features supported by some network devices and not others may force you to use a common denominator of standard features instead of the ones that best fit your application. An example would be a network scanner (master) that supports polled I/O but not change of state.

You’ll also find that some old designs don’t conform to the current specification. And undocumented features or capabilities in an open network can force you to use a particular controller or brand of software for full operation.


Photo 1. The DeviceNet Detective (FactoryComm Tools) is a dedicated network diagnostic tool that speeds network troubleshooting. Peak Systems offers a similar tool for CAN. ComSoft makes a handheld tool for Profibus. And numerous products are available from Fluke and others for Ethernet, ranging from physical layer testers to traffic analyzers.

In general, the Achilles’ heel of networks is wiring. Problems in this area can render the entire network inoperable, and it can be nearly impossible to determine where the problem physically exists. Good diagnostic tools are the best way to deal with this problem (see Photo 1).


As a precaution, many customers require that network-compatible devices be certified by independent labs. Certification makes no guarantee of product functionality; rather, it’s a series of rigorous lab exercises that fully test the communication characteristics of devices.

All the major network trade organizations have testing laboratories. The Profibus Interface Center in Johnson City, TN, and the Open DeviceNet Vendor Association’s lab in Ann Arbor, MI, both report an average of two or three tests before a product passes the test. Testing costs about $5000 per product, plus travel expenses.

The time and expense of certification brings up one of the strongest arguments for getting help from a network specialist. Whether it’s a matter of custom design, source code, plug-in modules, or gateways, a specialist will not only save you precious time but reduce the number of times you have to submit a product to the test lab for certification.

Product Development Snags

Poorly Written Specs. Most protocols are sophisticated and can be implemented in many degrees of complexity. Firmware for a bare-bones implementation can be written in two to three weeks; a fully functional master can take two or three programmer years. So define precisely the scope of your project.

Underestimating the Complexity. I once had a customer who called me and asked for a “DeviceNet master driver for Windows CE.” I explained to him that I had PC master cards for DeviceNet, and a CE driver for the card, but he insisted that he should be able to just stick a CAN chip on his motherboard and buy an off-the-shelf driver to do the DeviceNet part. I spent 30 minutes explaining that a DeviceNet master is significantly more complex than a mere driver. He eventually decided to use a system-on-a-chip, with licensed firmware and configuration tools because his volume did not justify a do-it-yourself project.

Adding Connectivity Reactively, Not Proactively. If you delay networking until a major customer forces your hand, time will be working against you. If you don’t have a road map for adding network capability to your product, you’ll run into the next problem, which is . . .

Your Biggest Customer, the Guinea Pig. A huge project comes along, and your customer will consider only network-capable devices. Unfortunately, your products are not network capable. So you assign one of your best engineers to a network-design project and tell the customer that you’ll have it done before the deadline.

There are few things that make a customer resent a vendor more than making a decision based on a promise and then finding itself so far into a project that it can’t switch to a different supplier. The customer’s anger grows as it is strung along through an indeterminate period of months. It swears it will never give you another dime.

You can prevent this by making a communications road map that accounts for multiple scenarios so you don’t get caught with your pants down.

Failure to Consider Multiple Networks. If you know you’re eventually going to have to support more than one network, keep this in mind from the beginning. Multiple-network support is best accomplished by building modularity into the design.

Failure to Fully Validate and Commission the Design. Test your product outside the laboratory. Find as many places as possible where you can safely put your product through its paces with real-world automation gear.

Failure to Train Your Customer. Make sure your customer gets the necessary training to ensure its employees know how to use your product. End users who are networking for the first time are advised to use a systems integrator with proven network expertise.

Wait! Before You Take the Plunge . . .

So far, I’ve given you the information you need to pick a network and to start gathering the specs and details from the appropriate sources. Don’t forget to check with the appropriate trade organization for additional information.

But before you go any further, wait until you read Part III of this series, which discusses the shortcuts and alternatives to creating network capability from scratch. Remember: if you start at zero, you’re reinventing the wheel. There are many ways to embed connectivity in your products without starting from scratch. Your options include PC cards, OPC and DDE servers, embedded plug-in modules, source code, binary code, turn-key reference designs, communication ASICs that incorporate microprocessors and memory, and even multinetwork systems on a chip.

What you choose depends on what your anticipated volume is, how fast your product needs to be put on the market, what engineering resources you have, and how many networks you need to support. Stay tuned.

Author’s Note

Synergetic offers a white paper, “Industrial Ethernet and 8 Popular Fieldbuses,” which goes into greater detail on device-level networks. It is available on request.