RS 485

RS-485 (also known as EIA-485) is an OSI Model physical layer electrical specification of a two-wire, half-duplex, multipoint serial connection.
The standard specifies a differential form of signalling. The difference between the wires’ voltages is what conveys the data. One polarity of
voltage indicates a logic 1 level, the reverse polarity indicates logic 0. The difference of potential must be at least 0.2 volts for valid operation,
but any applied voltages between +12 V and -7 volts will allow correct operation of the receiver.

Figure 3.2. RS-485 bus

EIA-485 only specifies electrical characteristics of the driver and the receiver. It does not specify or recommend any data protocol. EIA-485
enables the configuration of inexpensive local networks and multidrop communications links. It offers high data transmission speeds (35 Mbit/s
up to 10 m and 100 kbit/s at 1200 m). Since it uses a differential balanced line over twisted pair.

In contrast to EIA-422, which has a single driver circuit which cannot be switched off, EIA-485 drivers need to be put in transmit mode
explicitly by asserting a signal to the driver. This allows EIA-485 to implement linear topologies using only two lines. The equipment located
along a set of EIA-485 wires are interchangeably called nodes, stations and devices.
The recommended arrangement of the wires is as a connected series of point-to-point (multidropped) nodes, a line or bus, not a star, ring, or
multiply-connected network. Ideally, the two ends of the cable will have a termination resistor connected across the two wires. Without
termination resistors, reflections of fast driver edges can cause multiple data edges that can cause data corruption. Termination resistors also
reduce electrical noise sensitivity due to the lower impedance, and bias resistors are sometimes required. The value of each termination resistor
should be equal to the cable impedance (typically, 120 ohms for twisted pairs). Star and ring topologies are not recommended because of signal
reflections or excessively low or high termination impedance.

Converters from RS232 to RS485, USB to RS485, Ethernet to RS485 are available to allow a PC to communicate with remote devices. By using
repeaters and multi-repeaters very large RS485 networks can be formed. Using an RS485 multi-repeater can allow for star configurations with
home runs (or multi-drop) connections similar to Ethernet star implementations (with greater distances). Star systems (with multi-repeaters)
allow for very maintainable systems, without violating any of the RS485 specifications. Repeaters can also be used to extend the distance and/or
number of nodes on a network.

Bias resistors are sometimes used to bias data lines when the lines are not being driven by any device. This way, the lines will be biased to
known voltages and nodes will not interpret the noise from undriven lines as actual data; without biasing resistors, the data lines float in such a
way that electrical noise sensitivity is greatest when all device stations are silent or unpowered.

Often in a master-slave arrangement when one device dubbed "the master" initates all communication activity, the master device itself provides
the bias and not the slave devices. In this configuration, the master device is typically centrally located along the bus so it would be two slave
devices located at the physical end of the wires that would provide the termination. The master device would provide termination if it itself was
located at a physical end of the wires. Note that it is not a good idea to apply the bias at multiple node locations, because, by doing so, the
effective bias resistance is lowered, which could possibly cause a violation of the EIA-485 specification and cause communications to
malfunction. By keeping the biasing with the master, slave device design is simplified and this situation is avoided.

EIA-485, like EIA-422 can be made full-duplex by using four wires, however, since EIA-485 is a multi-point specification, this is not necessary
in many cases. EIA-485 and EIA-422 can interoperate with certain restrictions.

 Connectors
 EIA-485 does not specify any connector. The following table lists some typical RS-485 signal pin assignments (RS-232, another serial
standard, listed here for comparison):

Figure 3.3. RS-485 pinout

 Pin assignment

The RS485 differential line consists of two pins:

o A '-' (TxD-/RxD-) inverting pin which is negative (compared to B) when the line is idle (ie data is 1).
o B '+' (TxD+/RxD+) non-inverting pin which is positive (compared to A) when the line is idle (ie data is 1).
 The RS-485 signalling specification states that signal A is the inverting or '-' pin and signal B is the non-inverting or '+' pin. This is in
conflict with the A/B naming used by a number of differential transceivers manufacturers, including the Texas Instruments application
handbook on RS422/485 communications (A=non-inverting, B=inverting). These manufacturers are incorrect, but their practice is in a
widespread use. Therefore, care must be taken when using A/B naming.

In addition to the A and B connections, the EIA standard also specifies a third interconnection point called C, which is the common
ground.

 Waveform example

The graph below shows potentials of the '+' and '−' pins of an RS-485 line during transmission of an RS-485 byte:

Figure 3.4. RS-485 signals

RS 232
RS-232 is a standard for serial binary data signals connecting between a DTE (Data terminal equipment) and a DCE (Data Circuit-terminating
Equipment). It is commonly used in computer serial ports. A similar ITU-T standard is V.24.

The Electronic Industries Alliance (EIA) standard RS-232-C[1] as of 1969 defines:

 Electrical signal characteristics such as voltage levels, signaling rate, timing and slew-rate of signals, voltage withstand level, short-
circuit behavior, maximum stray capacitance and cable length.
 Interface mechanical characteristics, pluggable connectors and pin identification.
 Functions of each circuit in the interface connector.
 Standard subsets of interface circuits for selected telecom applications.

The standard does not define such elements as character encoding (for example, ASCII, Baudot or EBCDIC), or the framing of characters in the
data stream (bits per character, start/stop bits, parity). The standard does not define protocols for error detection or algorithms for data
compression. The standard does not define bit rates for transmission, although the standard says it is intended for bit rates lower than 20,000 bits
per second. Many modern devices can exceed this speed (38,400 and 57,600 bit/s being common, and 115,200 and 230,400 bit/s making
occasional appearances) while still using RS-232 compatible signal levels.

Details of character format and transmission bit rate are controlled by the serial port hardware, often a single integrated circuit called a UART
that converts data from parallel to serial form. A typical serial port includes specialized driver and receiver integrated circuits to convert between
internal logic levels and RS-232 compatible signal levels.

Because the application of RS-232 has extended far beyond the original purpose of interconnecting a terminal with a modem, successor
standards have been developed to address the limitations. Issues with the RS-232 standard include:

 The large voltage swings and requirement for positive and negative supplies increases power consumption of the interface and
complicates power supply design. The voltage swing requirement also limits the upper speed of a compatible interface.
 Single-ended signaling referred to a common signal ground limit the noise immunity and transmission distance.
  Multi-drop (meaning a connection between more than two devices) operation of an RS-232 compatible interface is not defined; while
multi-drop "work-arounds" have been devised, they have limitations in speed and compatibility.
 Asymmetrical definitions of the two ends of the link make the assignment of the role of a newly developed device problematic; the
designer must decide on either a DTE-like or DCE-like interface and which connector pin assignments to use.
 The handshaking and control lines of the interface are intended for the setup and takedown of a dial-up communication circuit; in
particular, the use of handshake lines for flow control is not reliably implemented in many devices.
 While the standard recommends a connector and pinout, the connector is large by current standards.

In RS-232, data is sent as a time-series of bits. Both synchronous and asynchronous transmissions are supported by the standard. In addition to
the data circuits, the standard defines a number of control circuits used to manage the connection between the DTE and DCE. Each data or
control circuit only operates in one direction, that is, signaling from a DTE to the attached DCE or the reverse. Since transmit data and receive
data are separate circuits, the interface can operate in a full duplex manner, supporting concurrent data flow in both directions. The standard does
not define character framing within the data stream, or character encoding.

 Voltage levels

The RS-232 standard defines the voltage levels that correspond to logical one and logical zero levels. Valid signals are plus or minus 3 to
15 volts. The range near zero volts is not a valid RS-232 level; logic one is defined as a negative voltage, the signal condition is called
marking, and has the functional significance of OFF. Logic zero is positive, the signal condition is spacing, and has the function ON. The
standard specifies a maximum open-circuit voltage of 25 volts; signal levels of ±5V,±10V,±12V, and ±15V are all commonly seen
depending on the power supplies available within a device. RS-232 drivers and receivers must be able to withstand indefinite short circuit
to ground or to any voltage level up to +/-25 volts. The slew rate, or how fast the signal changes between levels, is also controlled.

Because the voltage levels are higher than logic levels used by integrated circuits, special intervening circuits are required to translate
logic levels, and to protect circuitry internal to the device from short circuits or transients that may appear on the RS-232 interface.

Because both ends of the RS-232 circuit depend on pin seven the ground being zero volts, problems will occur when connecting
machinery and computers where the voltage between pin seven on one end, and pin seven on the other is not zero i.e. a condition that is
commonly referred to as a ground loop.
 Connectors

RS-232 devices may be classified as Data Terminal Equipment (DTE) or Data Circuit termination Equipment (DCE); this defines at each
device which wires will be sending and receiving each signal. The standard recommended but did not make mandatory the common D-
subminiature 25 pin connector. In general, terminals have male connectors with DTE pin functions, and modems have female connectors
with DCE pin functions. Other devices may have any combination of connector gender and pin definitions.

Presence of a 25 pin D-sub connector does not necessarily indicate an RS-232C compliant interface. For example, on the original IBM
PC, a male D-sub was an RS-232C DTE port (with a non-standard current loop interface on reserved pins), but the female D-sub
connector was used for a parallel Centronics printer port. Some personal computers put non-standard voltages or signals on their serial
ports. The standard specifies 20 different signal connections. Since most devices use only a few signals, smaller connectors can be used.
For example, the 9 pin DE-9 connector was used by most IBM-compatible PCs since the IBM PC AT, and has been standardized as TIA-
574. More recently, modular connectors have been used. Most common are 8 pin RJ-45 connectors.

 Pinouts (DTE relative)

Figure 3.1. RS-232 pinouts

The signals are labeled from the standpoint of the DTE device; TD, DTR, and RTS are generated by the DTE and RD, DSR, CTS, DCD,
and RI are generated by the DCE. The ground signal is a common return for the other connections; it appears on two pins in the Yost
standard but is the same signal. Connection of pin 1 (protective ground) and pin 7 (signal reference ground) is a common practice but not
 recommended. Use of a common ground is one weakness of RS-232. If the two pieces of equipment are far enough apart or on separate
power systems, the ground will degrade between them and communications will fail; this is a difficult condition to trace.

 Signals

Commonly-used signals are:

o Transmitted Data (TxD)

Data sent from DTE to DCE.

o Received Data (RxD)

Data sent from DCE to DTE.

o Request To Send (RTS)

Asserted (set to 0) by DTE to prepare DCE to receive data. This may require action on the part of the DCE, e.g. transmitting a
carrier or reversing the direction of a half-duplex line.

o Clear To Send (CTS)

Asserted by DCE to acknowledge RTS and allow DTE to transmit.

o Data Terminal Ready (DTR)

Asserted by DTE to indicate that it is ready to be connected. If the DCE is a modem, it should go "off hook" when it receives this
signal. If this signal is de-asserted, the modem should respond by immediately hanging up.
 o Data Set Ready (DSR)

Asserted by DCE to indicate an active connection. If DCE is not a modem (e.g. a null-modem cable or other equipment), this
signal should be permanently asserted (set to 0), possibly by a jumper to another signal.

o Carrier Detect (CD)

Asserted by DCE when a connection has been established with remote equipment.

o Ring Indicator (RI)

Asserted by DCE when it detects a ring signal from the telephone line.

 Cables

Since the standard definitions are not always correctly applied, it is often necessary to consult documentation, test connections with a
breakout box, or use trial and error to find a cable that works when interconnecting two devices. Connecting a fully-standard-compliant
DCE device and DTE device would use a cable that connects identical pin numbers in each connector (a so-called "straight cable").
"Gender changers" are available to solve gender mismatches between cables and connectors. Connecting devices with different types of
connectors requires a cable that connects the corresponding pins according to the table above. Cables with 9 pins on one end and 25 on
the other are common, and manufacturers of equipment with RJ-45 connectors usually provide a cable with either a DB-25 or DE-9
connector (or sometimes interchangeable connectors so they can work with multiple devices).

Connecting two DTE devices together requires a null modem that acts as a DCE between the devices by swapping the corresponding
signals (TD-RD, DTR-DSR, and RTS-CTS). This can be done with a separate device and two cables, or using a cable wired to do this. If
devices require Carrier Detect, it can be simulated by connecting DSR and DCD internally in the connector, thus obtaining CD from the
remote DTR signal. One feature of the Yost standard is that a null modem cable is a "rollover cable" that just reverses pins 1 through 8
on one end to 8 through 1 on the other end.
 For configuring and diagnosing problems with RS-232 cables, a "breakout box" may be used. This device normally has a female and
male RS-232 connector and is meant to attach in-line; it then has lights for each pin and provisions for interconnecting pins in different
configurations.

The reason that a minimal two-way interface can be created with only 3 wires is that all the RS-232 signals share a common ground
return. The use of unbalanced circuits makes RS-232 susceptible to problems due to ground potential shifts between the two devices. RS-
232 also has relatively poor control of signal rise and fall times, leading to potential crosstalk problems. RS-232 was recommended for
short connections (15 meters or less), however the limit is actually defined by total capacitance.

 Handshaking

The standard RS-232 use of the RTS and CTS lines is asymmetrical. The DTE asserts RTS to indicate a desire to transmit and the DCE
asserts CTS in response to grant permission. This allows for half-duplex modems that disable their transmitters when not required, and
must transmit a synchronization preamble to the receiver when they are re-enabled. There is no way for the DTE to indicate that it is
unable to accept data from the DCE.

A non-standard symmetrical alternative is widely used: CTS indicates permission from the DCE for the DTE to transmit, and RTS
indicates permission from the DTE for the DCE to transmit. The "request to transmit" is implicit and continuous.

 3-wire and 5-wire RS-232

A minimal "3-wire" RS-232 connection consisting only of transmit data, receive data, and ground, is commonly used when the full
facilities of RS-232 are not required. When only flow control is required, the RTS and CTS lines are added in a 5-wire version.

 Loopback testing

A commonly used version of loopback testing doesn't involve any special capability of either end. A hardware loopback is simply a wire
connecting complementary pins together in the same connector. For example, a device's transmit pin connected to its receive pin will
result in the device receiving exactly what it transmits. Moving this looping connection to the remote end of a cable adds the cable to this
 test. Moving it to the far end of a modem link extends the test further. This is a common troubleshooting technique and is often combined
with a Bit Error Rate Tester (BERT) that sends specific patterns and counts any errors that come back.

20 mA current loop uses the absence of 20 mA current for high, and the presence of current in the loop for low; this signaling method is often
used for long-distance and optically isolated links. Connection of a current-loop device to a compliant RS-232 port requires a level translator;
current-loop devices are capable of supplying voltages in excess of the withstand voltage limits of a compliant device. The original IBM PC
serial port card implemented a 20 mA current-loop interface, which was never emulated by other suppliers of plug-compatible equipment.

Other serial interfaces similar to RS-232:

 RS-422 (a high-speed system similar to RS-232 but with differential signaling)

 RS-485 (a descendant of RS-422 that can be used as a bus in multidrop configurations)
PC serial port
A serial port is a serial communication physical interface through which information transfers in or out one bit at a time in contrast to a parallel
port. Throughout most of the history of personal computers, data transfer through serial ports connected the computer to devices such as
terminals or modems. Mice, keyboards, and other peripheral devices also connected in this way.

While such interfaces as Ethernet, FireWire, and USB all send data as a serial stream, the term "serial port" usually identifies hardware more or
less compliant to the RS-232 standard, intended to interface with a modem or with a similar communication device.

For the most part, the USB interface has replaced the serial port as of 2007, most modern computers are connected to devices through a USB
connection, and often don't even have a serial port connection. The serial port is omitted for cost savings, and is considered to be a legacy port.

Compared with RS-232, USB is faster, has lower voltage levels, and has connectors that are simpler to connect and use. Both protocols have
software support in popular operating systems. USB is designed to make it easy for device drivers to communicate with hardware. However,
there is no direct analog to the terminal programs used to let users communicate directly with serial ports. USB is more complex than the RS 232
standard, requiring more software to support the protocol used. Serial ports of personal computers were also often used to directly control
various hardware devices, such as relays or lamps, since the control lines of the interface could be easily manipulated by software. This isn't
feasible with USB which requires some form of receiver to decode the serial data.

The IBM PC, used an integrated circuit called a UART, that converted characters to (and from) asynchronous serial form, and automatically
looked after the timing and framing of data. While the RS-232 standard originally specified a 25-pin D-type connector, many designers of
personal computers chose to implement only a subset of the full standard: they traded off compatibility with the standard against the use of less
costly and more compact connectors (in particular the DE-9 version used by the original IBM PC-AT).

Operating systems usually use a symbolic name to refer to the serial ports of a computer. Unix-like operating systems usually label the serial port
devices /dev/tty* where * represents a string identifying the terminal device; the syntax of that string depends on the operating system and the
device. The Microsoft MS-DOS and Windows environments refer to serial ports as COM ports: COM1, COM2, etc.
When a laptop does not have a serial port, two popular substitutes are USB adapters and PCMCIA cards. USB adapters often fail to work with
older "legacy" devices. A more expensive PCMCIA card provides a real (hardware) serial port. If communication with RS 232 devices is
critical, a physical RS 232 port will generally provide better compatibility with "legacy" software.

A virtual serial port is an emulation of the standard serial port. This port is created by special software products which enable extra serial ports in
operation system without additional hardware installation (such as expansion cards, etc.). Unlike the standard physical serial port the virtual one
can be assigned any name (COM255, VSP33, etc.). It is possible to create unlimited number of virtual serial ports in your PC. The only
limitation is the computer performance, as it may require a substantial amount of resources to emulate large numbers of serial ports. Virtual
serial port emulates all serial port functionality, including Baud rate, Data bits, Parity bits, Stop bits, etc. Additionally it allows controlling the
data flow, emulating all signal lines (DTR/DSR/CTS/RTS/DCD/RI) and customizing pinout.

Virtual serial port emulation can be useful in case there is a lack of available physical serial ports or they do not meet the current requirements.
For instance, virtual serial ports can help you share data between several applications from one GPS device connected to serial port. Another
option is to communicate with any other serial devices via internet or LAN as if they are locally connected to computer (Serial-over-Ethernet
technology). You can establish connection between two computers or applications via emulated null-modem link.

Setting up a serial port requires the following parameters to be configured on both the transmitter and the receiver:

 Baud rate

Serial ports use two-level (binary) signalling, so the data rate in bits per second is equal to the symbol rate in baud. Common bit rates per
second for asynchronous start/stop communication are 300, 1200, 2400, 9600, 19200 baud, etc.Though the RS-232 standard is formally
limited to 20,000 bits per second, serial ports on popular personal computers allow settings up to 115,200 bits per second; the capability
to set a bit rate does not imply that a working connection will result.

The speed includes bits for framing (stop bits, parity, etc.) and so the effective data rate is lower than the bit transmission rate. For
example for 8-N-1 encoding only 80% of the bits are available for data (for every eight bits of data, two more framing bits are sent).

 Data bits
 The number of data bits can be 5 (for Baudot Code), 6 (rarely used), 7 (for true ASCII), 8 (for any kind of data, as this matches the size
of a byte), or 9 (rarely used). 8 data bits are almost universally used in newer applications. Most serial communications designs send the
data bits within each byte LSB (Least Significant Bit) first. This standard is also referred to as "little endian". Also possible, but rarely
used, is "big endian" or MSB (Most Significant Bit) first serial communications.

 Parity

Parity is a method of detecting some errors in transmission. Where parity is used with a serial port, an extra data bit is sent with each data
character, arranged so that the number of 1 bits in each character, including the parity bit, is always odd or always even. If a byte is
received with the wrong number of 1 bits, then it must have been corrupted. If parity is correct there may have been no errors or an even
number of errors. A single parity bit does not allow implementation of error correction on each character, and communication protocols
working over serial data links may have higher-level mechanisms such as checksums to ensure data validity and request retransmission
of data that has been incorrectly received.

The parity of the serial can be set to none (N), odd (O), even (E), mark (M), or space (S). None means that no parity bit is sent at all.
Mark parity means that the parity bit is always set to the mark signal condition (logical 1) and likewise space parity always sends the
parity bit in the space signal condition. Mark or space parity is uncommon, as it adds very little error detection information. Odd parity is
more common than even, since it ensures that at least one state transition occurs, which makes it more reliable. The most common parity
setting, however, is "none", with error detection handled at higher layers of the protocol.

 Stop bits

Stop bits are sent at the end of every byte transmitted in order to allow the receiving signal hardware to resynchronise. Electronic devices
usually use one stop bit. Occasionally, and especially if slow electromechanical devices are used, one-and-one half or two stop bits are
required.

 Conventional notation
 The D/P/S conventional notation specifies the framing of a serial connection. The most common usage on microcomputers is 8/N/1
(8N1). This specifies 8 data bits, no parity, 1 stop bit. In this notation, the parity bit is not included in the data bits. 7/E/1 (7E1) means
that an even parity bit is added to the seven data bits for a total of eight bits between the start and stop bits.

 Flow control

A serial port may use signals in the interface to pause and resume the transmission of data. For example, a slow printer might need to
handshake with the serial port to indicate that data should be paused while the mechanism advances a line. Common hardware handshake
signals use the RS-232 RTS/CTS, DTR/DSR signal circuits.

Another method of flow control may use special characters such as XON/XOFF to control the flow of data. The XON/XOFF characters
are sent by the receiver to the sender to control when the sender will send data, that is, these characters go in the opposite direction to the
data being sent. The XON character tells the sender that the receiver is ready for more data. The XOFF character tells the sender to stop
sending characters until the receiver is ready again. If the control characters are part of the data stream, they must be sent as part of an
escape sequence to prevent data from being interpreted as flow control. Since no extra signal circuits are required, XON/XOFF flow
control can be done on a 3 wire interface.
Modbus protocol
Modbus is a serial communications protocol published by Modicon in 1979 for use with its programmable logic controllers (PLCs). It has
become a de facto standard communications protocol in industry, and is now the most commonly available means of connecting industrial
electronic devices. The main reasons for the extensive use of Modbus over other communications protocols are that it is a published protocol that
is royalty-free and easy to implement.

Modbus allows for communication between many devices connected to the same network. Modbus is often used to connect a supervisory
computer with a PLC or a RTU in supervisory control and data acquisition (SCADA) systems. Versions of the Modbus protocol exist for serial
port and Ethernet.

Figure 3.5. Modbus network

Two variants of Modbus exist, with different representations of numerical data and slightly different protocol details. Modbus RTU is a compact,
binary representation of the data. Modbus ASCII is human readable, and more verbose. Both of these variants use serial communication. The
RTU format appends the commands/data with a cyclic redundancy check checksum, while the ASCII format uses a longitudinal redundancy
check checksum. Nodes configured for the RTU variant will not communicate with nodes set for ASCII, and the reverse. Modbus/TCP is very
similar to Modbus RTU, but transmits the protocol packets within TCP/IP data packets.

An extended version, Modbus Plus (Modbus+ or MB+), also exists, but remains proprietary to Modicon. It requires a dedicated co-processor to
handle fast HDLC-like token rotation. It uses twisted pair at 1 Mbit/s and includes transformer isolation at each node, which makes it
transition/edge triggered instead of voltage/level triggered. Special interfaces are required to connect Modbus Plus to a computer.

Figure 3.6. Modbus application layer

Each device intended to communicate using Modbus is given a unique address. Any device can send out a Modbus command, although usually
only one master device does so. A Modbus command contains the Modbus address of the device it is intended for. Only the intended device will
act on the command, even though other devices might receive it. All Modbus commands contain checking information, ensuring that a command
arrives undamaged. The basic Modbus commands can instruct an RTU to change a value in one of its registers, as well as commanding the
device to send back one or more values contained in its registers. There are many modems that support Modbus. Some of them were specifically
designed for this protocol. Different implementations use wires, wireless communication and even SMS or GPRS. Typical problems the
designers have to overcome include high latency and timing problems.

Almost all implementations have variations from the official standard. Different varieties may not communicate correctly between different
suppliers equipment. Some of the most common variations are:

Data Types

* Floating Point IEEE

* 32 bit integer
* 8 bit data
* mixed data types
* bit fields in integers
* multipliers to change data to/from integer.

Protocol extensions

* 16 bit slave addresses

* 32 bit data size (1 address = 32 bits of data returned.)
* word swapped data

Modbus was designed in the late 1970's to communicate to programmable logic controllers and sufers from limitations by modern standards. The
number of data types are limited to those understood by PLCs at the time. Large binary objects are not supported. No standard way exists for a
node to find the description of a data object, for example, to determine if a register value represents a temperature between 30 and 175 degrees.
Since Modbus is a master/slave protocol, there is no way for a field device to "report by exception" - the master node must routinely poll each
field device, and look for changes in the data. This consumes bandwidth and network time in applications where bandwidth may be expensive,
such as over a low-bit-rate radio link. Modbus is restricted to addressing 254 devices on one data link, which limits the number of field devices
that may be connected to a master station. Modbus transmissions must be contiguous which limits the types of remote communications devices
to those that can buffer data to avoid gaps in the transmission.

Modbus is an application layer protocol. Modbus is a stateless client-server protocol similar to HTTP based on transactions. A transaction
consists of a request (issued by the client) and a response (issued by the server). Modbus is usually deployed in a master-slave polling
configuration. To prevent confusion "master-slave" in terms of the "client-server" paradigm is related as follows:

* the master is a client

* the slave is a server

Figure 3.7. Modbus client/server

The stateless communication is based on a simple package, that is called Protocol Data Unit (PDU). The protocol specification defines three
types of PDU's:

 Request PDU, consisting of:

o a code specifying a function (Function Code, 1 byte)
o function specific data (Function Data, varying number of bytes)
 Response PDU, consisting of:
o the function code corresponding to the request (Function Code, 1 byte)
o response specific data (Response Data, varying number of bytes)
 Exception Response PDU, consisting of:
o the function code corresponding to the request + 0x80 (128), (Error Code, 1 byte)
o a code specifying the exception (Exception Code, 1 byte)

Figure 3.8. Modbus Protocol Data Units

The Modbus specification defines a certain number of functions, each of which is assigned a specific function code. These are in the range 1-127
(decimal), as 129(1+128)- 255(127+128) represents the range of error codes. Categories of function codes are the following:

 Public

Guaranteed to be unique and specify well defined functions that are publicly documented. These are validated by the community and a
conformance test exists.

 User-Defined

Available for user-defined functions, thus their codes might not be unique. The specification defines the code ranges 65-72 and 100-110
for user-defined functions.

 Reserved

Currently used by some companies for legacy products and are not available for public use.

Figure 3.9. Modbus function codes

The documentation for a function consists of:

 Description of the function, it's parameters and return values (including possible exceptions).
 Assigned Function Code.
 Request PDU.
 Response PDU.
 Exception Response PDU.
In certain cases, the response from a slave will be an exception. The primary identification of an exception response is the error code (function
code + 128), which is further specified by the exception code.

Figure 3.10. Modbus error codes

The basic public functions have been developed for exchanging data typical for the field of automation. The specification does not define the
ways of organizing the related data in a device. However, the organization has a direct influence on the addresses used in basic access functions.
The device's documentation must always be consulted to learn about device specific addressing conventions for basic access functions.

Figure 3.11. Modbus data types

The Modbus application protocol defines precisely PDU addressing rules. In a Modbus PDU each data is addressed from 0 to 65535. It also
defines clearly a Modbus data model composed of 4 blocks that comprises elements numbered from 1 to n. The Modbus data model has to be
bound to the device application. The pre-mapping between the Modbus data model and the device application is totally vendor device specific.

Figure 3.12. Modbus device mapping

Examples of Modbus messages:

 Read coil

Figure 3.13. Modbus read coil

 Read discrete input

Figure 3.14. Modbus read input

 Figure 3.15. Modbus read input example

 Modbus read holding register

Figure 3.16. Modbus read holding register

 Modbus read input register

Figure 3.17. Modbus read input register

 Modbus write single coil

Figure 3.18. Modbus write single coil

Figure 3.19. Modbus write single coil example

 Modbus write single register

Figure 3.20. Modbus write single register

Modbus has been implemented and used over all types of physical links (wire, fiber and radio) and various types of lower level communication
stacks. Modbus started it's life in form of an implementation for asynchronous serial network communication. The application level protocol
operates directly on top of a serial interface and serial communication standards. The most common ones are on the RS232 and RS485 physical
layers.

The Modbus header is composed of an address field (1 byte) and the tail is an error checksum over the whole package, including the address
field (i.e. header). For transmission the Modbus message (i.e. ADU) is placed into a frame that has a known beginning and ending point,
allowing detection of the start and the end of a message and thus partial messages. There exist two transmission modes, which differ in encoding,
framing and checksum:

 ASCII
 Frames are encoded into two ASCII characters per byte, representing the hexadecimal notation of the byte (i.e. characters 0 - 9, A - F).
The error checksum is represented by a longitudinal redundancy check (LRC; 1 byte) and messages start with a colon (':', 0x3A), and end
with a carriage return-line feed ("CRLF", 0x0D0A). Pauses of 1 second between characters can occur.

 RTU

Frames are transmitted binary to achieve a higher density. The error checksum is represented by a cyclic redundancy check (16 bit CRC;
2 byte) and messages start and end with a silent interval of at least 3.5 character times. This is most easily implemented as a multiple of
character times at the baud rate that is being used on the network. The maximum pause that may occur between two bytes is 1.5 character
times.
DNP3 protocol
(Distributed Network Protocol) is a set of communications protocols used between components in process automation systems. Its main use is in
utilities such as electric and water companies. Usage in other industries is not common, although technically possible. Specifically, it was
developed to facilitate communications between various types of data acquisition and control equipment. It plays a crucial role in SCADA
systems, where it is used by SCADA Master Stations (Control Centers), Remote Terminal Units (RTUs), and Intelligent Electronic Devices
(IEDs). It is used only for communications between a master station and RTUs or IEDs. ICCP, the Inter-Control Centre Protocol, is used for
inter-master station communications.

While IEC 60870-5 was still under development and had not been standardized, there was a need to create a standard that would allow
interoperability between various vendors SCADA components for the electrical powergrid. Thus, in 1993, GE-Harris Canada used the partially
completed IEC 60870-5 protocol specifications as the basis for an open and immediately implementable protocol that specifically catered to
North American requirements. The protocol is designed to allow reliable communications in the adverse environments that electric utility
automation systems are subjected to, being specifically designed to overcome distortion induced by EMI, aging components (their expected
lifetimes may stretch into decades), and poor transmission mediums. The DNP3 protocol is also referenced in IEEE Std. 1379-2000, which
recommends a set of best practices for implementing modern SCADA Master-RTU/IED communication links.

Figure 3.21. DNP3 protocol stack

Although the protocol was designed to be reliable, it was not designed to be secure from attacks by hackers and other malevolent forces that
could potentially wish to disrupt control systems to disable critical infrastructure. Thus, much work is currently being done to provide security
for the systems that use the DNP3 protocol.
DNP3 consists of, in standard networking terms, a layer 7 (application) and a layer 2 (data link) protocol. It provides multiplexing, data
fragmentation, error checking, link control, prioritization, and layer 2 addressing services for user data. It makes particularly heavy use of Cyclic
Redundancy Checks (CRCs) embedded in its data packets, in an attempt to deal with the very noisy environments in which it is typically used.

Many modern applications can now carry DNP3 messages over TCP/IP.

Figure 3.22. DNP3 architecture

Common DNP3 network architectures are depicted in Figure 3.21, “DNP3 protocol stack”. At the top is a simple one-on-one system having one
master station and one outstation deployed on a RS232 physical layer typically over dial-up telephone line. The second figure shows a
configuration known as a multi-drop design over RS485 physical layer. One master station communicates with multiple outstation devices with a
master-slave polling communication routine.
A DNP3 frame consists of a header and data section. The header specifies the frame size, contains data link control information and identifies
the DNP3 source and destination device addresses. The data section contains data or payload passed down from the application layers above.

Figure 3.23. DNP3 data frame

The link layer has the responsibility of making the physical link reliable by providing error detection and duplicate frame detection. The link
layer sends and receives frames. A frame begins with two sync bytes that help the receiver determine where the frame begins. The length
specifies the number of octets in the remainder of the frame, not including CRC check octets.

The destination address specifies which DNP3 device should process the data, and the source address identifies which DNP3 device sent the
message. Having both destination and source addresses satisfies at least one requirement for peer-to-peer communications because the receiver
knows where to direct its responses. 65520 individual addresses are available. Every DNP3 device must have a unique address within the
collection of devices sending and receiving messages to and from each other. Three destination addresses are reserved by DNP3 to denote a
broadcast message; that is, the frame should be processed by all receiving DNP3 devices.

The data payload in the link frame contains a pair of CRC octets for every 16 data octets. This provides high resolution in detecting errors. The
maximum number of octets in the data payload is 250, not including CRC octets. The maximum length link layer frame is 292 octets if all the
CRC and header octets are counted.

An important feature of DNP3's link layer is the ability for the transmitter of the frame to request the receiver to confirm that the frame arrived.
Using this feature is optional, and it is often not employed because there are other methods for confirming receipt of data. It provides an extra
degree of assurance of reliable communications. If a confirmation is not received, the link layer may retry the transmission. Some disadvantages
to using link layer confirmation are the extra time required for handshaking over slow data links and waiting for multiple timeouts when retries
are configured.

The pseudo transport layer (level 7) has the responsibility of breaking long application layer messages into smaller packets sized for the link
layer to transmit, and, when receiving, to reassemble frames into longer application layer messages. In DNP3 the transport layer is incorporated
into the application layer. The transport layer requires only a single octet of overhead data to perform its duty. The link layer can handle only
250 data octets, and one of those is used for the transport function, each link layer frame can therefore hold as many as 249 application layer
octets.

Application layer messages are broken into fragments. Maximum fragment size is determined by the size of the receiving device’s buffer. The
normal range is 2048 to 4096 bytes. Fragmenting messages is the responsibility of the application layer. Note that an application layer fragment
of size 2048 must be broken into 9 frames by the transport layer, and a fragment size of 4096 needs 17 frames. Communications in noisy
environments are more successful if the fragment size is significantly reduced.

The application layer works together with the pseudo transport and link layers to enable reliable communications. It provides standardized
functions and data formatting with which the user layer above can interact. The term "static" is used with data and refers to the "current value".
Thus static binary input data refers to the present on or off state of a bi-state device. Static analog input data contains the value of an analog at
the instant it is transmitted. DNP3 allows requests for some or all of the static data in an outstation device.

DNP3 events are also supported for state changes, values exceeding some threshold, snapshots of varying data, transient data and newly
available information. For example, an event is triggered when a binary input changes from an on to an off state or when an analog value
changes by more than its configured deadband limit. Events can be generated with and without time stamps so that the master will have the
information to generate a time sequence report. The user layer can be configured to request events. Data updates are more rapidly when the
master spends most of its time polling for events from the outstation and only occasionally asks for static data as an integrity measure. Updates
are faster because the number of events generated between outstation interrogations is small and, therefore less data needs to be send back to the
master station. Events are classified into three classes. The user layer can request the application layer to poll for class 1, 2 or 3 events or any
combination of them.

DNP3 data is represented in various formats. As an example: analog data can be represented as follows:
* 32-bit integer value with flag
* 16-bit integer value with flag
* 32-bit integer value
* 16-bit integer value
* 32-bit floating point value with flag
* 64-bit floating point value with flag

The flag referred to is a single octet describing the state or quality of the data i.e. whether the source is on-line, the data source restarted,
communications are lost with a downstream source, the data is forced or the value is over range.

Data values are assigning by group numbers. Static analog values are assigned as group 30, and event analog values are assigned as group 32.
Static analog values, group 30, can be formatted in one of 6 variations, and event analog values, group 32, can be formatted in one of 8
variations. When an outstation transmits a message containing response data, the message identifies the group number and variation of every
value within the message. Group and variation numbers are also assigned for counters, binary inputs, controls and analog outputs. All valid data
types and formats are identified by group and variation numbers.

When data from an index is transmitted the sender must encode the information to enable a receiving device to parse and interpret the data. The
data for each index appearing in the message are encoded as binary objects i.e. the objects are classified according to the group and variation
number chosen. The user layer formulates requests for data from outstations by specifying what function to perform, such as reading, and by
specifying the data types required. The user layer specifies the amount of objects required as a range of objects from index number X through
index number Y. The application layer then passes the request down through the transport layer to the link layer for transmission to the out
stations.

Besides the reading of data the DNP3 protocol is designed to handle other functions. For example: the master can set the time in the outstation,
transmit requests for control operations and setting of analog output values.

DNP3 supports slave initiated responses i.e. a slave sends information without being polled for it - also referred to as unsolicited messages.
Rather than waiting for a master station polling cycle to get around to it, the outstation simply transmits the change. Before configuring a system
for unsolicited messages special attention must be paid to bus contention issues such as the following:
  Spontaneous transmissions should generally occur infrequently, otherwise, too much contention can occur, and controlling media access
via master station polling should be used.
 The outstation should have some way of knowing whether it can transmit without stepping on another outstation’s message. DNP3 leaves
specification of algorithms to the system implementer.

The DNP3 organization recognizes that supporting every feature of DNP3 is not necessary for every device. Some devices are limited in
memory and speed and do not need specific features, while other devices must have more advanced features to accomplish their task. DNP3
provides for complexity levels. At the lowest level, level 1, only very basic functions must be provided and all others are optional. Level 2
handles more functions, groups and variations, and level 3 is more sophisticated. Within each level a minimal subset of request formats and
response formats is specified.