It seems every controls-related publication contains at least one article on the Industrial Internet of Things (IIoT). However almost all are vaporware or exist in PowerPoint only, with few implementations that couldn’t have been done with existing, typically SCADA technology applied in new ways. One thing they all have in common, however, is they rely on Ethernet as their backbone.
As we know, there are different local area networks (LAN)/metropolitan area networks (MAN) defined by the IEEE 802 standards covering the data link (Layer 2) and physical (Layer 1) layers of the OSI Networking reference model. The most common ways of referring to these standards are by their physical media—fiber, copper and wireless—each with different bandwidths and design constraints. However, because a typical industrial network, especially one with a wireless sensor network, combines all three physical layers, the differences between each type of network needs to be managed from the design stage.
Fortunately, in most networks, the media we use tend to increase in capacity as we move from the wireless sensor in the field to the access point and then to the interface room. The wireless sensor network (WSN) is likely to be based on the IEEE 802.15.4 standard. And then, from the access point in, the protocol will be IEEE 802.11 (wireless)—if not from the WSN access point, then soon after from the Wi-Fi hub to IEEE 802.3 copper or fiber to the interface room. Once connected to a “physical” physical layer, the slowest speed is likely 100 MB/s in the copper CAT 5e or CAT 6 cable.
Fiber is frequently used in the facility for both its noise immunity, as well as its ability to handle long distances. Copper Ethernet is typically constrained to approximately 100 meters (300 feet or one football field). Fiber selection itself requires design choices from diameter (50 and 62.5 µm are the most common options) to materials (glass or plastic). Next, users choose step or graded index, and single- or multi-mode, with their selection typically based on corporate specifications and, often, on an agreement between the IT team and other users.
These teams often want to use the same media, not only fiber but more importantly, wireless, where the signals can’t be contained, so it’s critical that each facility have some mechanism to manage the site Ethernet spectrum. One simple way of doing this is to allocate different portions of the Industrial, Scientific and Medical (ISM) license-free bands to specific uses. Because recent versions of the IEEE 802.11 series can use both 2.4 GHz and 5.8 GHz, if you have the option, “reserving” the 2.4 GHz band for other uses is one easy option, then all you have to do is manage the channels within 2.4 GHz for the various users in that band.
Managing traffic is critical because the chance of a self-inflicted network failure increases with too many packets and not enough bandwidth. Think of this as a traffic jam, where a multi-lane road is designed for “n” cars per hour. After an accident (collisions), one or more lanes are out of service but the number of cars does not change. Unfortunately, just like a traffic jam, once a network exceeds a traffic threshold, collisions start to collide with themselves (gawkers causing more accidents), and the problem gets worse—quickly. The good news is that most network traffic management tools, such as switches, have intelligence to warn of this condition before it gets out of control.
Everyone expects their Ethernet to always work. However, without careful planning, keeping your end-to-end connections working and secure isn’t as easy as it appears. Compounding the problem will be increased demand for not only more information, but also for improved integration throughout an organization and potentially with clients. All of them using Ethernet as their base reaffirms, at least in my mind, the importance of getting the foundations right, or everything will come tumbling down.