Selecting I/O Units
I/O units typically are referred to as local or remote, a reference loosely interpreted to mean distance. I like to think of local as directly (or nearly directly) connected core processor peripherals. PCI- and ISA-enabled peripherals are good examples of local devices. A remote I/O unit usually has some kind of communication medium, such as a serial (RS-232 or RS-485) cable, wireless, infrared, Ethernet, FireWire or USB (to name a few). These remote interfaces have devices that may connect to the local core processor of the controlling computer but modify the data in such a way that it is transferred via another medium to its destination. This medium acts as an extension cord that extends the distance from the core processor bus to the device. This distance may be as short as a meter or as long as kilometers.
Remote vs. local I/O is important when considering the expense of additional cables to a control location. If I were to design a local control system using a set of PCI I/O cards, every point of I/O would have a cable installed. Consider a 1,000-point system with 1,000 cables. Just imagine the expense if an electrical contractor quoted an installation cost of $100 US per cable (the total would be $100,000 US)! In such a case, remote I/O allows a single wire such as CAT 5 (Ethernet) to be run to distributed I/O units. While 1,000 cables are still required for installation, the signal cable distance is shorter, decreasing the labor and materials cost of installation. In more unusual projects I've worked on, remote I/O implementation also provided incredible savings in cable weight. In one project, I recall estimating that we saved approximately 1,000kg of mass by just converting the system to remote I/O.
Shorter sensor and effector cables routed to a nearby I/O unit also are easier to test, debug and maintain. For example, if the cables run through a complex vehicle such as a ship or an airplane, a suspected wire failure might require physical cable tracing. If the wire length is 500 meters, each meter of wire may require inspection. If an I/O unit is located next to sensors and effectors, the communication media cable from the control computer to the I/O unit is still 500 meters, but it may be an Ethernet fiber bundle. The sensor and effector cables to the I/O unit may be only meters long. Clearly, debugging a couple of meters of wire is easier than several hundred meters.
Analog signals also may be affected by electrical noise, which places additional and undesirable signals into the analog data. Devices switching on and off may cause electrical noise. Power cables too close to sensitive signals also may create anomalies in I/O unit readings. Typically, the shorter the wire, the lower the probability of receiving electrical noise. Digital media cables such as copper Ethernet are susceptible to electrical noise too. Digital media typically employs a method of data validation that detects when data corruption occurs, but it still can be a problem.
Nonmetal technologies such as fiber are not susceptible to noise because they use light and not electrons. When installing a system it is useful to perform a site survey to evaluate potential sources of electrical noise. Plan for cables to be a significant distance from high-energy cables (power conductors, RF transmitters and so on) and high-energy systems (such as anodizing systems, high-voltage switching equipment and high-energy control hardware).
Modularity is all about selecting channels or points of I/O. While most I/O units support either all digital points or all analog points, some support both types. Mixed systems, as we call them, allow the designer to pick a single unit and select all the points required. As most systems require both analog and digital points, mixed I/O units optimize the cost-effectiveness of the design and reduce size and weight.
In addition, modularity improves life-cycle maintenance. An I/O unit with removable points may require a few seconds to replace a component and restore system operation. Replacing an entire I/O unit is much more costly in labor and downtime. Modularity also allows smaller, cheaper components to be stocked as spares should a replacement be necessary, also reducing downtime.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development