All Serial Communications Use the OSI Model

Before looking at RS-232 specifically, let’s discuss the OSI model for data communications. OSI is “Open Systems Interconnection.” The OSI model has been around since the late 1970s and is still very relevant. The model partitions a communication system into seven abstraction layers.

A layer serves the layer above it and is served by the layer below it. For example, a layer that provides error-free communications across a network provides the path needed by applications above it, while it calls the next lower layer to send and receive packets that comprise the contents of that path. Two instances at the same layer are visualized as connected by a horizontal connection in that layer. See the accompanying illustration.

OSI model

RS-232 Interfaces are Still Useful

Thanks to their simplicity and past ubiquity, RS-232 interfaces are still used—particularly in industrial machines, networking equipment, and scientific instruments where a short-range, point-to-point, low-speed wired data connection is fully adequate.

Per the OSI model the physical layer (level 1) is responsible for the transmission and reception of unstructured raw data between a device and a physical transmission medium. It converts the digital bits into electrical, radio or optical signals. RS-232 resides in the physical layer since the specification defines voltage levels and wire connections (pin-out). Although most devices climb up the layers slightly by adding stop bits and parity, which for practical purposes can be thought of as being part of the RS-232 specification.

Physical connections for serial communications use “D” shell connectors, named because they are shaped like a “D”. Below are DB-9, DB-15 and DB-25 connectors. RS-232 initially used the 25-pin but has evolved to the 9-pin. RS-232 communications may be involved if a piece of equipment has any of these.

DB-9, DB-15 and DB-25 Connectors

The Modbus standard defines an application layer messaging protocol, positioned at level 7 of the OSI model that provides “client/server” communications between devices connected on different types of buses or networks. It standardizes a specific protocol on a serial line to exchange Modbus requests between a master and one or several slaves. Basically this means that a Modbus-compliant device provides for the full data transfer per the OSI model. As a software developer using two Modbus devices, we can work at the highest application layer. We can send and receive data to a specific data location on a specific device and we’re done. The software layers in the OSI model are still there, but are done by the Modbus protocol.

Modbus is mentioned because it has been around forever, is simple, and is well documented. Many original equipment manufacturers (OEMs) still use Modbus protocol for data communications. Much of the data is useful not only for proper operation but for energy consumption. As OEMs modernize and get smarter about their equipment they make that data available and Modbus is still a viable way to extract the data. Of course we can also send data to OEM equipment via an RS-232 connection. This allows sending setup and running parameters to the equipment.

Interfacing to RS-232 Can Be a Challenge

As mentioned above OEMs still use RS-232, but we also need a way to interface to the OEM machine. Obviously computers can be used, but they are not as easy as one would imagine. Computers originally had an on-board RS-232 port, but that stopped years ago. A USB to RS-232 adapter is now required. The custom software is required to read and write data. In our industrial control environment programmable logic Controllers (PLCs) are extremely common and can be used to interface with RS-232 devices. Many PLCs still have an onboard RS-232 interface that can be used to transmit and receive simple data, like a scale weight. Software is still required, but can be much simpler.

Matrix has had experiences where we were asked to retrieve and send data from OEM equipment via Modbus. To do this we simply purchased a Modbus interface module, such as Prosoft. Understanding, collecting and presenting the OEM data was still required, but we did it at the application layer. All software required for the other layers was part of the Prosoft module.

Home-grown Protocol Creates Issues

Some OEMs may create their own protocol and use the RS-232 interface. The OSI model is still used, but the software to read and write the data per the OSI model is missing. In these cases it is necessary to create the layers per the OSI model. A protocol analyzer is a handy tool in these instances to help troubleshoot protocol issues. Sometimes documentation can be misleading or just missing.

Matrix has had experiences where a piece of equipment had valuable data and a description of how the data was assembled and sent, but that was all. The equipment just sent data out an RS-232 port. We were required to create the software to read the data without any structured protocol. In this case it isn’t necessary to build the entire OSI model, but conceptually all the layers are accounted for.

Conclusion

RS-232 was developed back when TV was in black and white, a radio in your car was an option, Gilligan had an island, and Watergate was just a hotel, but it is still relevant today. Just understanding that it exists and that it is possible to send and retrieve various operational parameters is important.

Matrix Technologies is one of the largest independent process design, industrial automation engineering, and manufacturing operations management companies in North America. To learn more about our automated manufacturing system capabilities and manufacturing process control solutions, contact Bob Taylor, Senior Engineer.

© Matrix Technologies, Inc.