Triangle MicroWorks Inc.
DNP3 Product Highlights
Features of DNP3 Source Code Libraries
What is Distributed Network Protocol?
DNP3 is a standards based communications protocol designed for the utility industry. It is an open protocol that
was developed to establish interoperability between RTUs, IEDs (Intelligent Electronic Devices) and master
stations. DNP3 has been adopted by the Substation Committee of the IEEE Power Society as a recommended
practice for RTU-IED communication.
Features Common to All of Our DNP3 Source Code Libraries
• Conforms to DNP3 Level 3+ Subset Definitions requirements.
• Written in ANSI Standard C Source Code, under a strict corporate coding standard.
• Easy installation through “Triangle” Source Code Library to Target Application interface. (See Design Details
for Implementation, and Technical Details for each specific product).
• Supports any physical communication network including RS 232/485 and TCP/IP.
• Can be used in event-driven or non-event-driven environments (with or without a Real Time Operating
System).
• Supports binary (input and output), analog (input, deadbands, and output), counter (running and frozen),
time objects, virtual terminal, and internal indications.
• Supports Unsolicited Responses and/or polled Report-By-Exception (RBE) for change event objects.
• Supports File Identifier for transferring large data blocks, e.g., configuration or oscillographic (COMTRADE) data.
• Supports function codes for confirm, read, write, select, operate, direct operate, freeze, freeze and clear,
cold/warm restart, assign class, enable/disable unsolicited response, and delay measurement.
• Supports qualifier codes for start-stop range (0x00, 0x01), all points (0x06), limited quantity
(0x07, 0x08), indexed (0x17, 0x28), and free format (0x1B).
• Large response messages can consist of multiple data link frames and multiple application layer fragments.
• Simple configuration for byte-order: most-significant-first (Motorola) or least-significant-first (Intel).
• Extensive, built-in (but removable) diagnostics including a protocol analyzer used to visually decipher
protocol messages. The diagnostic and analyzer strings can be directed to any target system display device,
even a serial port or RAM buffer. See the back of this page for sample protocol analyzer output.
• Records number of communication protocol errors such as bad CRC, invalid synchronization byte, and incorrect
frame sequence number to help identify faulty communication lines.
• No royalty fees per unit sold.
• Typical product integration times are less than 3 weeks.
DNP3 Slave Source Code Library Features
• Database manager maps randomly organized Target Application data points (binaries, controls, integers,
floats, etc.) into sequential points within DNP3 object groups.
• Multiple examples of simulated Database Interface implementations are provided for testing, illustration, and
as templates to be used for developing final Database Interface.
• Report-by-Exception data can be automatically generated by configurable scans of Target Application data.
• Built-in (but removable) ASCII terminal command interface may be used to change configuration parameters
or to simulate input data changes during testing.
• Supports Virtual Terminal objects for embedding other protocols such as the included ASCII terminal interface
within DNP3 messages.
— Continued on back of this page — 000701000002
DNP3 Master Source Code Library Features
• An unlimited number of remote devices can be configured on an unlimited number of communication ports,
and new remote devices can be added at runtime.
• Multiple devices can be assigned to the same communication port to support multiple network communication
topologies.
• ASCII terminal based SCADA Man Machine Interface (MMI) can be used to initiate DNP3 commands, read
requests, freeze operations, etc.
• Database manager maps received DNP3 data objects into Target Application data points (binaries, controls,
integers, floats, etc.).
Protocol Analyzer Display created by DNP3 Source Code Library
The following symbols are used to denote data from each layer of the protocol:
==== User Layer Operations
<~~~ Application Transmit
~~~> Application Receive
<--- Transport Transmit
---> Transport Receive
<... Link Transmit
...> Link Receive
Type "HELP" for a list of commands ...
-Initialization successful on \\.\COM1 baud=9600 parity=N data=8 stop=1
<=== ch00 0003<=0003 PLACE MESSAGE IN USER REQUEST QUEUE WITH PRIORITY 4 FOR
EVENT CLASS DATA POLL
<~~~ ch00 0003<~0003 APPLICATION HEADER - READ for user request:
EVENT CLASS DATA POLL
First:1 Final:1 ReqCnfm:0 Sequence:02
<--- ch00 0003<-0003 TRANSPORT HEADER - First:1 Final:1 Sequence:01
<... ch00 0003<.0003 PRIMARY LINK HEADER - UNCONFIRMED USER DATA
FCV:0 FCB:0 DIR:1 Length:017
05 64 11 C4 03 00 03 00 24 39
C1 C2 01 3C 02 06 3C 03 06 3C 04 06 65 F1
...> ch00 0003.>0003 PRIMARY LINK HEADER - UNCONFIRMED USER DATA
FCV:0 FCB:0 DIR:0 Length:046
05 64 2E 44 03 00 03 00 F1 95
CA E2 81 00 00 02 02 17 04 00 81 C9 E9 C0 C2 E1 0B F3
00 01 20 C9 E9 C0 C2 E1 00 02 81 C9 E9 C0 C2 E1 39 94
00 03 01 C9 E9 C0 C2 E1 00 DB 3D
---> ch00 0003->0003 TRANSPORT HEADER - First:1 Final:1 Sequence:10
~~~> ch00 0003~>0003 APPLICATION HEADER - RESPONSE TO REQUEST
First:1 Final:1 ReqCnfm:1 Sequence:02 IIN:0x0000
<~~~ ch00 0003<~0003 APPLICATION HEADER - CONFIRM
First:1 Final:1 ReqCnfm:0 Sequence:02
<--- ch00 0003<-0003 TRANSPORT HEADER - First:1 Final:1 Sequence:02
===> ch00 0003=>0003 STORE RESPONSE o02v02: Binary Input Change with Time
Binary Input Point 00000 = 0x81 22Sep00 15:04:24.265 Absolute
Binary Input Point 00001 = 0x20 22Sep00 15:04:24.265 Absolute
Binary Input Point 00002 = 0x81 22Sep00 15:04:24.265 Absolute
Binary Input Point 00003 = 0x01 22Sep00 15:04:24.265 Absolute
===> ch00 0003=>0003 CALLBACK TO USER PROCESS WITH RESULTS OF REQUEST FOR
EVENT CLASS DATA POLL
i i i l
2840 PLAZA PLACE, SUITE 205 • RALEIGH, NC 27612 • PH: 919.870.5101
FAX: 919.870.6692 • WEB SITE: www.TriangleMicroWorks.com
Triangle MicroWorks, Inc. Design Details for Implementation
Efficient Installation, Testing, and Verification
Design Objective:
Our primary design objective is to provide our customers with an ANSI Standard C Source Code Library (SCL)
with a Target Application (TA) Interface that can be implemented in less than three man weeks. To accomplish
this, our design divides the interface into “entry-points” from TA-to-SCL, and “calls” back into the TA from the
SCL.
The “Triangle” Approach to Interfacing between the SCL and TA:
The interface between the SCL and TA can be viewed as a three-sided, or “triangle” interface. Two sides
represent calls back into the TA from the SCL Interface. Each of these sides is organized into individual, well-
documented modules or header files. These files are the only recommended customer-editable (or platform-
specific) files. All other files are protocol-specific and should not need to be modified by the customer.
The three sides of the interface are shown in the diagram below:
1) TA-to-SCL Entry Points: The entry points are limited to a few SCL initialization functions and a single
process function; the process function can be called regularly as part of a Target Application main loop,
or as an event-driven task in a real-time operating system environment. Master Source Code Libraries
also provide C function calls to build and send request messages to remote Slave devices.
2) Low-Level Target Interface: Provides access to hardware components such as communication channels,
timers, and clocks.
3) Database Interface: Provides customized fit to TA data, and allows extraction and insertion of individual
database profiles, including any of our included simulated database profiles used for testing.
Example flow diagram for an installation of the DNP3 Slave Source Code Library
Low-Level Target Interface Database Interface
(to your hardware) (to your data)
example calls from SCL:
example calls from SCL:
Triangle sdnpdata_binInRead()
tmwtarg_receive()
tmwtarg_transmit() MicroWorks, Inc. sdnpdata_anlgOutOperate()
Source Code Library (SCL)
Target Application (TA)
(your mainline software)
tmwappl_initApplication() /* initialize all configuration structures to defaults */
tmwtarg_initConfig();
dnpchnl_initConfig();
sdnpsesn_initConfig();
... /* overwrite default config values with user settings */
tmwtimer_initialize(); /* initialize polled timer (if used) */
dnpchnl_openChannel(); /* open channel */
sdnpsesn_openSession(); /* open session */
...
while(1) /* begin main loop or task */
{
...
tmwpltmr_checkTimer(); /* if using SCL in polled mode, check timer and */
tmwappl_checkForInput(); /* check for received data. These lines are not */
... /* required if using SCL in event-driven mode */
}
— Continued on back of this page — 000715000003
Typical Installation Sequence for All Source Code Libraries
We strongly recommend that before you develop any communications protocol, whether or not you use our
Libraries, you should create a Configuration/Interoperability (C/I) Guide that conforms to standard “device
profile” documents for each protocol. The C/I Guide specifies how to configure the protocol operation of the
device; for interoperability, it specifies the objects, variations, and protocol functions that will be implemented.
Our Source Code Libraries come with C/I Guide templates, with much of the information already filled in.
After completing the C/I Guide, a typical sequence to install one of our Source Code Libraries is:
1) Edit low-level target interface file to attach serial port receive and transmit functions, add access to a
free-running millisecond timer/counter, and to configure byte-order (most or least significant first).
2) Add TA-to-SCL entry point functions in Target Application software (as in the DNP3 example above).
3) Conduct initial testing, which verifies operation of the Source Code Library on the target hardware. Initial
testing consists of comparing results of requests and polls with known values from either a simulated
database (for Slave Libraries), or from a known slave device (for Master Libraries). Slave Libraries include
simulated database profiles with pre-set initial values of database objects; no modification of the database
interface is necessary for initial testing.
4) Attach SCL-to-TA calls to your database design by simple replacement of simulated database calls.
5) For Slave Libraries, install report-by-exception processing by adding access to a date/time clock, and
configuring scan periods and event buffer sizes.
6) For Master Libraries, install Target Application request messaging by adding calls to build request message
entry points from Target Application software.
7) Make final adjustments of the configuration interface to ensure that all user settable configuration
parameters are mapped to SCL configuration structures.
8) Conduct final testing.
Testing and Diagnostics
For testing Source Code Library installations, we provide the following tools:
• A built-in protocol analyzer allows you to visually decipher protocol messages to or from both Master
and Slave devices.
Sample Protocol Analyzer display
15:28:37.506: ...> slave 05 64 14 c4 04 00 03 00 c7 17
15:28:37.506: ...> slave ca c9 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 f8
15:28:37.506: ae
15:28:37.506: ---> slave Primary Frame - Unconfirmed User Data
15:28:37.506: LEN(20) DIR(1) PRM(1) FCV(0) FCB(0) DEST(4) SRC(3)
15:28:37.506: 05 64 14 c4 04 00 03 00 c7 17
15:28:37.506: ca c9 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 f8 ae
15:28:37.506: ~~~> slave Transport Header
15:28:37.506: FIR(1) FIN(1) SEQ# 10
15:28:37.506: ca c9 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06
15:28:37.506: ===> slave Application Header, Read Request
15:28:37.506: FIR(1) FIN(1) CON(0) UNS(0) SEQ# 9
15:28:37.506: c9 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06
15:28:37.506: Object 60(Class Data), variation 2, qualifier 0x06(All Points)
15:28:37.506: Object 60(Class Data), variation 3, qualifier 0x06(All Points)
15:28:37.506: Object 60(Class Data), variation 4, qualifier 0x06(All Points)
• Triangle MicroWorks also offers a Communication Protocol Test Harness to facilitate version release
testing of your Source Code Library implementation. The Test Harness acts as a simple Master or Slave
device and can also be programmed with automated test sequence scripts. Conformance Test Scripts are
also available to perform the conformance test procedures published by the technical committees of each
protocol. Please contact us for more information on this product or download a full 21-day evaluation
from our website at http://www.TriangleMicroWorks.com/downloads.htm.
2840 PLAZA PLACE, SUITE 205 • RALEIGH, NC 27612 • PH: 919.870.5101
FAX: 919.870.6692 • WEB SITE: www.TriangleMicroWorks.com
