OSI 7-layer model is tough to follow

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.”

OVDA promotes media-independent platforms called the common industrial protocol (CIP). Adaptations today include EtherNet/IP, DeviceNet,  ControlNet, and a newly coined CompoNet.

The benefits of CIP networks are a bit vague when trying to determine ROI for a networking project. These benefits can include a suite of messages for manufacturing automation, producer/consumer architecture, seamless bridging and routing, common application interface, interoperability between multi-vendor systems, and stable, open technologies.

Though quantifying benefits can be difficult, organizations such as ODVA and others, influenced greatly by certain vendors, have a major impact on what users decide to do in the future.

A different approach is taken by B&R Industrial Automation, founder and chief promoter of Ethernet PowerLink, one of the more prominent European real-time network protocols. Markus Sandhoefner, sales manager, argues that “PowerLink provides significant benefits over other protocols because it uses IP protocol transfer, which is important for easy communications between nodes. It’s a non-hardware-based solution, which is important since hardware-based solutions are faster, but more rigid. And a 100% software-based solution allows seamless technology upgrades.”

Sandhoefner adds that the device network organization is standardized on one device profile rather than multiple profiles that require far more integration and investment by the user. “It is deterministic,” he states, "and it supports one-microsecond jitter rates.”

Taking yet another tack is Motion Engineering, a component of Danaher Motion. More than six years ago, networking requirements for real-time motion applications in the semiconductor industry couldn’t be solved using the available technology. This requirement drove Motion Engineering to create SynqNet, a hardware-intensive, proprietary, real-time motion network. “Of all the real-time configurations, SynqNet perhaps deviates most from the OSI model,” says Marshall Matheson, product line manager for SynqNet controls. “The SynqNet network model, which is supported by such servo motion suppliers as AMC, Danaher, Glentech, Panasonic and Yaskawa, has more than 60,000 axes installed.”

For the average network-hungry engineer, these solutions are difficult to parse. No one appears to have a major advantage over another, particularly regarding the notion of determinism. After all, once a set of commands can be delivered in a consistently repeatable fashion that’s greater than any machine’s ability to respond—regardless of variables involved—determinism is realized. More bandwidth beyond what is necessary to satisfy more than 80% of all motion applications (200-300 μs refresh rates) isn’t really necessary except for specmanship, and some expectation of future needs.