Print page

Email page

OSI 7-layer model is tough to follow

Industrial Networking, ControlDesign.com

Today, the implementation of the Open System Interconnect (OSI) Seven-Layer model has taken on different looks as technology strives for real-time performance over the stack.

By Loren Shaum

THE OPEN SYSTEM Interconnect (OSI) Seven-Layer model originally was developed by the International Standards Organization (ISO). It describes how applications running network-enabled devices communicate with each other. As a generic model, it applies to any network configuration. The layers are well-known to most network-savvy people, but not totally understood by many potential users.

Fundamentally, when an application is running through the layers, or stacks as they’re often called, it usually starts at the user or application layer. Packets of information descend the stack until they reach the device addressed at Layer 1. Then new information might be obtained, which ascends back up the stack. As the packet migrates through the various stacks, it’s configured with various headers and trailers, as required by the protocols at each layer in the stack. As the information ascends, the packet is unbundled completely of headers and trailers when it reaches the application layer.

A common example is a TCP/IP transmission. In the seven-layer stack, TCP (Transmission Communication Protocol) lies in Layer 4 as the transporting method. IP (Internet Protocol) is in Layer 3. So we have TCP/IP, or “TCP over IP.”

A packet of information might be rerouted to Layer 3 if it isn’t transmitted, perhaps by a busy router. Rerouting occurs when the sender fails to receive an acknowledgement from the addressed device.

Today, implementation of OSI’S Seven-Layer model has taken on different looks as technology strives for real-time performance over the stack. Motion control over an Ethernet-type of connection has made great strides recently, but the methodology involved with implementing the model varies dramatically from vendor to vendor. Moreover, as the data rates increase to accommodate applications as rigorous as servo-update requirements, the potential for more packet collisions occurs. Ethernet switches now have sufficient capability to avoid most collisions, but some still occur as the rates climb. To handle these higher data rates for real-time applications many vendors deviate from the seven-layer model.

There are at least 14 different industrial Ethernet solutions, and at least seven motion control protocols. Table I below compares six well-known motion control solutions over Ethernet.

TABLE 1: COMMON ETHERNET PROTOCOLS FOR REAL-TIME OPERATIONS

So, what’s so different with each of these protocols if they use the model as their basis for real-time networking? The answer lies in what they do to bypass the model to maintain determinism. Vendors basically bypass the intrinsically non-deterministic data-link layer with a proprietary, custom link to improve speed and provide determinism. Mechanisms include scheduling update cycles into specific time slots, proprietary gateways that place non-motion packets into UDP formats, proprietary hardware and software to control transmissions, and polling schedules for slave nodes.

Despite all the performance claims, there’s a fine line between various networks. ODVA, one of the keepers of several of the more-common fieldbus and Ethernet protocols, expands the model further, claiming a right to be different because most everyone has their own standard. “There is no one-size-fits-all solution,” says Katherine Voss, ODVA’s executive director. “Plants often require more than one network. The problem is that most networks are optimized for a specific application without regard to overall architecture. As a result, extra resources are required to integrate these networks. Users typically compromise their investment and rarely achieve all the gains promised by open network technology.”