Phone: 818-785-6200
FAX: 818-785-4415
Application Note APP-1129
The CAP SCADA Protocol.
Why is the CAP protocol so widely
used?
Many protocols are proprietary (not open to the public).
Others are obsolete and are no longer supported by
the manufacturer. Other protocols, such as MODBUS,
have become virtual standards for communicating with
PLCs by virtue of their wide use. Every manufacturer
tries to make a forceful case for using his own
particular protocol. Which one to use?
The protocol requirements of PLCs (Programmable
Logic Controllers) and RTUs (Remote Telemetry
Units) differ in a number of aspects:
PLCs, most often used in factory floor and other local
control systems, need rapid access to read and
change single individual points
RTUs, used in SCADA systems, need rapid access to
all their information for quick central station screen
updates. It is impractical to repeatedly ask for point
after point in these systems.
This application note describes the CAP protocol in
detail.
Why is the CAP protocol preferred for all
modern SCADA systems?
1. CAP uses ASCII (American Standard Code For
Information Interchange) format:
ASCII interfaces directly with all modern SCADA
software such as Lookout. ASCII was specifically
designed to allow computers, printers, modems and
other devices to communicate with each other over
sometimes noisy and questionable lines. It has built in
transmission security and error checking and it is an
open protocol, easily written and interpreted. It is used
all over the world.
Email: scandata@aol.com
Web Site: www.scan-data.com
APP-1129
06-01-00
What is a protocol?
A protocol is simply the language the RTUs,
computers and other devices use when they
communicate with each other.
Protocols have proliferated and today there are
hundreds of them. Many are proprietary (not
public) and are designed to lock the end user into
a specific manufacturer's product.
The worlds first protocol was the Morse code, a
series of dots and dashes. It travelled along
railroad lines on iron wires and reached ships at
sea over radios and flashing lights. Remember the
most famous Morse code message of them all,
SOS, Save Our Souls?
The Morse code is a bit protocol, difficult to read.
You have to interpret each set of bits.
Bit protocols are still used, especially in
proprietary systems and in large and complex
SCADA systems for electric power distribution.
PLC protocols are often bit oriented as they are
designed to read and command single specific
inputs or outputs. "Turn coil #214 on" is a typical
PLC command. These bit protocols are difficult to
handle by humans and by computers.
Two protocols now dominate the world. The first,
obviously, is plain speech (English, Chinese,
Norwegian, whatever). It dominates. Just listen to
your TV or radio or mother in law. Even RTUs use
this plain speech protocol. Check the ScanData
VBX-7 Voice Box Supervisor RTU.
The second dominating protocol is ASCII,
American Standard Code for Information
Interchange. It has been accepted by the whole
world. Virtually all computers and printers and
modems and what have you now communicate in
ASCII. It is an excellent RTU protocol, easily
generated and read by all computers.
2 .CAP compresses data values:
Compressing certain information saves space and
transmitting time. Transmitting each status (contact) bit
of information as one character, for instance, would be
wasteful. These are therefore compressed, typically
four status bits into one character. Compressing the
ASCII RTU message gives us CAP (Compressed
ASCII protocol) which is used all over the world.
3. CAP separates the data into blocks
Modern software such as Lookout has made it easy to
configure computers to transmit, receive and display
information to and from RTUs. This is made even
easier when the RTU messages are organized by the
CAP protocol into well defined separate elements as
described in this application note.
4. CAP uses start and stop message identifiers.
Your computer software has to know when the RTU
transmission starts, so that it can point to a buffer. It
also has to know where it ends, so that it can close its
communication port and ignore the garbage
characters that invariably follow, especially over radio
when the carrier turns off. .
To make it easy to read the RTU messages during
testing, the start identifying character should be a line
feed (LF) and the end character should be a carriage
return (CR). In this manner, the message will be easy
to read during tests as it scrolls up on the computer
screen or on the printer.
The CAP message, formatted with these start and stop
identifiers, looks like this :
(LF)RTU message (CR)
5. CAP uses a message security checksum
character.
There may be errors during a transmission due to
noisy lines or to radio static. The software must have a
way of finding out if this has happened so that it can
disregard the message and ask the RTU to transmit
another one (see sidebar).
A checksum character (CS) is therefore transmitted
before the message stop character, as follows:
(LF)RTU message (CS)(CR)
This checksum is a running sum of all the bits of all the
characters transmitted, ignoring all carry past 6 bits
and sent as a printable ASCII character. If the received
APP-1129, Page 2
message has too many or too few bits, this transmitted
checksum will not match with the checksum
calculated by the receiving software.
Message Security.
The information transmitted by an RTU is often used
in automatic process control and used by operators
to take vital action, such as turning pumps on and off,
opening and closing valves, etc.
This means that no errors in the transmission can be
tolerated. The slightest error in a message makes the
whole message suspect. The message must then
be rejected and a new message requested. This
must be repeated until an error free message is
received.
The effect of these re-transmissions is that updates
on noisy lines will be slow. On a noisy radio circuit,
for example, you will see how an analog value in a
Mode-C signal multiplexer system slowly updates,
with long pauses in between the updates. With good
error checking you will never see an erroneous
message.
How do you check for errors? Complex schemes for
long messages, such as Cyclic Redundancy Check
(CRC), stick parity, etc., have been used. These are
available for ScanData RTUs on special order but are
not needed for short RTU messages.
A four level error check is used in the CAP protocol.
First, each individual character is checked for parity,
overrun and framing. After this rigorous test the
whole message is checked to see if the total count of
all the received bits in all the characters matches the
transmitted count of bits (checksum check). This
method has resulted in no reported errors in many
years of operating RTUs.
For instance, a Mode-C leak detect system was
delivered many years ago to the then Getty Oil in
central California, working over very noisy VHF
splinter frequency radios. Four ScanData RTUs at
crude oil custody transfer stations deliver CAP
protocol leak detect and metering pulse counts to a
central ScanData RTU. No erroneous counts have
ever been reported with this system.
6. CAP uses message delineators.
Your computer software needs to know where the
information starts and where it ends in the received
message string. There may be garbage characters at
the beginning and at the end. If the message is
transmitted over radio there may certainly be some
garbage characters.
The message delineators are usually a pair of '{ }' (so
dear to Pascal programmers). The CAP message now
looks like this:
(LF){ RTU message }(CS)(CR)
The software now knows exactly where the message
starts and where it ends. This is essential for the
checksum calculation. If there is any flaw in any of the
characters in the message (inside these delineators) or
if the checksum does not match, the message is
discarded and another one asked for.
7. CAP uses a protocol version identifier:
There are different versions of the CAP protocol suit
different applications. Some transmit analog
information in compressed form, others transmit it in
ASCII digits, etc. The receiving software needs to know
which version is in use.
Which particular CAP protocol version is the RTU
using? The protocol identifier character tells you. It
follows the space after the message start delineator.
For instance, where a 'B' version protocol is used, the
message looks like this:
(LF){ BRTU message }(CS)(CR)
8. CAP uses a station identifier (address).
Each RTU has its own three character identifying
code. For example, receiving a message from an
RTU in 'B' protocol with the identifier XYZ reads:
(LF){ BXYZRTU message }(CS)(CR)
9. CAP uses a message type identifier.
What type of message is it? A command, a report, a
register request or other? Each type of message has
its own identifying character. The report message
identifier character is normally an exclamation mark '
! '. It follows the station identifier:
(LF){ BXYZ!RTU message }(CS)(CR)
10. CAP has an RTU configuration field.
APP-1129, Page 3
Some RTUs have only a few analog and digital inputs
and outputs, others have lots of them. How many
inputs and outputs does this RTU have? And what kind
are they? The software needs to know an the RTU
configuration field has the information.
The configuration field contains five pairs of numbers.
Certain protocols use five groups of three numbers.
These five numbers follows the message type
identifier. The first number tells you how many analog
inputs the RTU has, the second pair how many pulse
counter inputs it has, the third pair how many digital
inputs it has, the fourth how many digital outputs (relay
drivers) it has and finally the fifth pair tells you how
many analog outputs the RTU has.
For example, an RTU with 8 analog inputs, 2 pulse
counter inputs, 8 digital inputs, 8 digital outputs and 1
analog output (a version of the ScanData LMX RTU)
has the following configuration field:
(LF){ BXYZ!0802080801RTU message }(CS)(CR)
11. CAP uses separate data fields.
The RTU reports its analog, pulse counter and digital
input readings in three data fields. It reports the
contents of its analog and digital output buffers in two
more data fields. Five data fields in total. The RTU
automatically dimensions its report data field size by
the information in its configuration field. No RTU
reporting space is wasted.
12. Example of a complete CAP RTU report.
For example, a complete report from an LMR RTU
with the identifier 513, with a D version protocol and
with 2 analog inputs, 1 counter input, 2 digital inputs, 2
digital outputs and 1 analog output, reads as follows:
(LF){ D513!0201020201 FAGM 54321 A B EG
}(CS)(CR)
This is a very small RTU so the five data fields, FAGM
(two analog inputs), 54321 (one pulse count input), A
(status inputs), B (relay driver outputs) and EG (analog
output) are short. Larger RTUs will have
correspondingly larger data fields. The fields are
always placed in these positions, however, with spaces
between each field. Unused fields therefore occupy
two spaces. This way the software knows exactly
where each data group is and knows exactly how
many data groups there are of each kind.
Lets examine the whole message in our example:
(LF) is the start of transmission character.
{ is the start of message character.
D is the protocol version identifier.
513 is the station identifier.
! is the message type identifier, in this case a complete
RTU report.
0201020201 is the RTU configuration field. It means
that the RTU is equipped as follows:
0201020201: 2 analog inputs.
0201020201: 1 pulse counter input.
0201020201: 2 digital inputs.
0201020201: 2 digital outputs.
0201020201: 1 analog output.
FAGM is the analog input report field. Two
compressed analog values are reported in this field,
FA and GM, corresponding to the RTUs analog input
#1 and #2. These are binary values, 8 bits, where the
high order 4 bits are reported in the first character and
the low order 4 bits are reported in the second
character.
54321 is the pulse counter input report field. It is
reported in straight ASCII numericals and means that
the pulse counter has counted 54,321 pulses.
A is the compressed status input report field,
corresponding to the RTU status inputs 1 and 2.
'A' is a binary representation an indicates that status
input #1 is 'ON".
B is the compressed status output (relay driver)
condition report field, corresponding to the RTU relay
driver outputs 1 and 2. 'B' indicates that relay driver
output #2 is 'ON'.
EG is the compressed analog output register report
field, corresponding to the RTU analog output #1.
Same compression as with the analog inputs.
} is the end of message character.
(CS) is the checksum character.
APP-1129, Page 4
(CR) is the end of transmission character.
CAP Polling Requests:
Polling requests to an RTU normally very short. All the
RTU needs to know is that the polling request
concerns this particular RTU and that it is a polling
request (message identifier '!'). This polling request will
cause RTU 513 to answer with a report:
(LF)513!(CS)(CR).
When manually polling the RTU from a keyboard, you
can omit the checksum (which may be difficult for you
to calculate on the fly) by sending this polling
message:
(LF)513!!(CR)
Sending the message identifier twice causes the RTU
to ignore the checksum calculation.
CAP commands to the RTU:
Commands to an RTU are also normally much shorter
than the RTU reports and are therefore easier to
configure. The same message elements described
above are used, with the following additions:
Command message type identifier.
The command message identifier is normally a
percent sign '%'. If it is transmitted twice it will cause
the RTU to ignore the checksum check. This is very
valuable when you are testing an RTU as you don't
have to calculate the checksum each time you
manually type in a command to the RTU. For
example, to manually send a command to an LMX
RTU with identifier 'XYZ' to turn relay driver #5 'ON',
type the following string:
(LF)XYZ%%R051(CR)
(LF) is the start of transmission character. Press ctrl 'j'
on your PC keyboard.
XYZ is the station identifier.
%% is the command message identifier. It tells the
RTU that a command follows.
R05 identifies relay driver (status output) #5.
1 tells the RTU to turn this relay driver 'ON'. 0 would
have told the RTU to turn this relay driver 'OFF'.

Note that no checksum character needs to be

included, as the message type identifier character is
transmitted twice

(CR) is the end of transmission character, Press

'Enter' on your keyboard.

You type these commands manually when you test

an RTU. Normally, a computer or another RTU sends
these codes. They know how to calculate and place
the checksum and therefore send only one command
message identifier.

Other Commands and Reports.

In addition to the above, many other requests,
commands and reports are available. For instance,
multiple registers and large data bases are used in gas
calculating RTUs for variables and constants. These
registers are written into and read out over the CAP
protocol, using three letter data base tag designators.

Summary:
The public domain CAP protocol is in use in systems
all over the world. It is fast, flexible virtually error free
and adapts easily to different RTU configurations and
functions. Complete CAP protocol manuals are
delivered with each ScanData RTU.

Most modern software, like National Instruments'

Lookout (voted the world's best SCADA software) all
have built in drivers for the CAP protocol.

This application note, together with many other helpful

application notes, additional technical information and
prices, is available on our WEB site:
www.scan-data.com

You can also call us, 818-785-6200 for help during

US West Coast business hours.

APP-1129, Page 5