RESUMEN PROTOCOLO DNP3

El protocolo DNP3 (Distributed Network Protocol) fue desarrollado por Harris en 1993 con la
finalidad de tener un estándar de comunicación para lograr la interoperabilidad entre Unidades
Terminales Remotas, Dispositivos Electrónicos Inteligentes y Unidades Terminales Maestras para
aplicaciones SCADA enfocadas a la industria Eléctrica, con este protocolo podemos:

Direccionar hasta 65000 dispositivos

Direccionar hasta 4,000,000,000 puntos
DNP Sincronización de tiempo
Eventos con estampado de tiempo

DNP esta basado en estándares de IEC que lo hacen un protocolo abierto y de dominio público,
basándose en el modelo ISO-OSI de 7 capas como se observa a continuación.

Application

Presentation

Session

Transport

Network

Data Link

Physical

Modelo OSI

A continuación se describen las características de cada capa.

Capa Física. En esta capa se definen las características eléctricas y mecánicas de la red necesarios
para establecer y mantener la conexión física (se incluyen las dimensiones físicas de los conectores
los cables y los tipos de señales que van a utilizar). Ejemplo la interfaz RS232 es un estándar para
PC.
Capa de Enlace de Datos. Es la responsable de accesar a la red y transmitir los blocks de datos de
un dispositivo a otro. En esta capa es donde se especifica el protocolo de comunicación.
Capa de Red. Esta capa se encarga de decidir por donde se han de transmitir los datos dentro de la
red (se incluye la administración y gestión de los datos, la emisión de los mensajes y la regulación
del trafico de la red). Entre los protocolos mas utilizados en esta capa esta el IP (Internet Protocol),
IPX (Internetwork Packet Exchange) de Novell.

AbelG Resumen Dnp3.0 Página 1 de 13

 Capa de Transporte. Esta capa se encarga de asegurar la transferencia de información a pesar de los
fallos que pudieran ocurrir en los niveles anteriores ( se incluye la detección de bloqueos, caídas del
sistema, asegurar la igualdad entre la velocidad de transmisión y recepción). Entre los protocolos
mas utilizados en esta capa esta el TCP (Transmissión Control Protocol), SPX (Sequenced Packet
Exchange) de Novell.

Capa de Sesión. Esta capa permite que dos usuarios se comuniquen a través de la red (se incluyen
las tareas de seguridad, las contraseñas de usuarios y la administración del sistema).

Capa de Presentación. Traduce la información del formato de máquina a un formato entendible

por los usuarios (se incluye el control de las impresoras, la emulación de terminal y los sistemas de
codificación).

Capa de Aplicación. Se encarga del intercambio de información entre los usuarios y el sistema
operativo (se incluye la transferencia de archivos y los programas de aplicación).

De estas siete capas las cuatro primeras tienen funciones de comunicación y las tres restantes de
proceso, donde las capas inferiores proporcionan servicios a los niveles superiores, cada capa
dispone de un conjunto de servicios y cada servicio esta definido mediante protocolos.

De este modelo el protocolo DNP3 se basa en el modelo EPA (Enhanced Performance Architecture)
de Arquitectura Mejorada la cual consiste de la capa Física, capa de Enlace de Datos y la capa de
Aplicación, como se observa a continuación.

Physical Layer
EPA Data Link Layer
Application Layer

A continuación se indica los servicios de cada una de las capas utilizadas en el protocolo DNP3

Convierte octetos a datos seriales (bits)

Proporciona las señales de control para el medio de comunicación
Capa Física Reporta el estado del medio de comunicación (ejemplo enlace ocupado)
Medio físico
Envía los datos recibidos a Data Link Layer
Interfaz RS232, RS485

Transfiere mensajes entre otras capas

Transmite y Recibe mensajes a y desde la capa física
Capa de Enlace Agrega el encabezado y CRC (Código de Redundancia Cíclica) a los mensajes de la
de Datos capa de aplicación
Provee servicios de SEND-CONFIRM, SEND-NO REPLY, REQUEST-RESPONSE
Mensajes de longitud variable

AbelG Resumen Dnp3.0 Página 2 de 13

 Es la mas alta define por ejemplo la función del mensaje (ejemplo leer entradas
Capa de analógicas)
Aplicación
Envía y recibe mensajes completos
Se comunica con base de datos y con la capa de enlace.

La capa de enlace es la segunda capa en el modelo OSI y su función es transferir información de la

capa física hacia otras capas de nivel superior y viceversa para su transmisión para lo cual utiliza el
formato FT3, y es en el que se basa el protocolo DNP3, a continuación se describe la estructura de
este formato.

FT3 Frame Format de LPDU (Link Protocol Data Unit). Esta definido como 1 block de 10 bytes
identificado como “Header Block”, seguido de blocks opcionales de datos, cada block es de 16
bytes con su CRC al final de cada block.

La especificación IEC indica que el “Header Block” (block 0) esta formado por 2 bytes de inicio o
encabezado, 1 byte que indica el tamaño o longitud del mensaje, 1 byte de control, 2 bytes para la
dirección destino, 2 bytes para la dirección fuente y 2 bytes para el código de seguridad CRC. Como
se observa en la imagen Estructura formato FT3.

El o los siguientes blocks de datos conocidos como “User Data” cada uno es de 16 bytes, excepto el
último block el cual puede ser menor de acuerdo a la función solicitada.

A continuación se muestra la estructura de FT3.

Block 0 Block1 Block n

START START LENGTH CONTROL DESTINATION SOURCE CRC USER CRC USER CRC
0X05 0X64 DATA DATA

Fixed Length Header Body

10 octets

Estructura formato FT3

START Son los 2 bytes del encabezado, su valor es en hexadecimal y es el mismo valor
tanto en mensajes solicitud como de respuesta, el 1er byte es igual a 05 y el segundo
byte es igual a 64. Dentro del mensaje son los 2 primeros bytes

LENGTH Indica el número de bytes que se van a transmitir, en este contador se incluyen los
bytes de CONTROL, DESTINATION y SOURCE, los códigos de CRC no se incluyen
en el número de bytes que se transmiten, así como los tres bytes de START(2) y
LENGHT(1).

El valor mínimo para LENGTH es 5 y el máximo 255, este campo ocupa el tercer
byte en el mensaje.

AbelG Resumen Dnp3.0 Página 3 de 13

CONTROL Este byte contiene la dirección del mensaje, el tipo e información del flujo de control.
Es el cuarto byte en el mensaje. Este byte se encuentra estructurado de la siguiente
forma:

1 FCB FCV Primary to Secondary

DIR PRIM FUNCTION CODE
0 RES DFC Secondary to Primary

Bit 7 6 5 4 3 2 1 0

A continuación se indica la información de los bits o banderas utilizados en este

byte.

DIR (Direction Bit) Este bit se utiliza para indicar la dirección física de transmisión
del mensaje con relación a la estación maestra designada, donde la estación
A es la maestra, cuando es de UTM a UTR el valor de DIR es 1 y de UTR a
UTM es 0.

PRM (Primary Message Bit) Este bit indica la dirección de quien envía el mensaje es
decir si es del primario o del secundario, si este bit vale 1 lo envía el
primario y si es cero lo envía el secundario

FCB (Frame Count Bit) Este bit es utilizado para indicar duplicidad de mensajes a la
misma estación. Inicialmente antes de comunicarse con 1 estación
secundaria o después de una falla de comunicación la estación primaria
deberá resetear el Data Link de cada estación secundaria. Cada estación
secundaria después de 1 falla no deberá aceptar ningún mensaje SEND-
CONFIRM estando la bandera FCV=1 hasta la recepción del comando
RESET y el envío del mensaje CONFIRM.

FCV (Frame Count Valid) Habilita la bandera FCB, si el valor de FCV es igual a 0 el
estado de FCB es ignorado, si vale 1 indica a la estación secundaria que el
estado de FCB deberá ser checado otra vez de el último mensaje enviado con
la bandera FCV habilitada.

DFC (Data Flow Control) Este bit es usado para indicar un Overflow en una estación
secundaria, el bit es colocado por la estación secundaria ocasionando que la
estación primaria deberá interrogar a la secundaria con el comando
REQUEST-RESPOND, Request Link Status hasta que DFC=0.

FUNCTION CODE se utilizan 4 bits y son para identificar el tipo de mensaje el cual
es diferente para el primario o para el secundario de acuerdo al estado del
bit PRM y al valor asociado a FCV. A continuación se muestran los códigos
de función para el Primario y secundario.

AbelG Resumen Dnp3.0 Página 4 de 13

 Function Code Field of the Control Octect Sent from the Primary Station (PRM=1)
Function Frame Type Service Function FCV
Code Bit
0 SEND-CONFIRM expected RESET of remote link 0
1 SEND-CONFIRM expected Reset of user process 0
2 SEND-CONFIRM expected TEST function for link 1
3 SEND-CONFIRM expected User data 1
4 SEND-NO REPLY expected Unconfirmed User Data 0
5 Not Used -
6 Not Used -
7 Not Used -
8 Not Used -
9 REQUEST-RESPON expected REQUEST LINK STATUS 0
10 Not Used -
11 Not Used -
12 Not Used -
13 Not Used -
14 Not Used -
15 Not Used -

Function Code Field of the Control Octect Sent from the Secondary Station (PRM=0)
Function Frame Type Service Function
Code
0 CONFIRM ACK positive acknowledgement
1 CONFIRM NACK Message not accepted, link busy
2 Not Used
3 Not Used
4 Not Used
5 Not Used
6 Not Used
7 Not Used
8 Not Used
9 Not Used
10 Not Used
11 RESPOND Status of Link (DFC=0 or DFC=1)
12 Not Used
13 Not Used
14 Link service not functioning
15 Link service not used or implemented

Table of Primary and Secondary Function Codes

DESTINATION Este campo utiliza 2 bytes y nos indican la dirección de la estación a la cual se esta
enviando el mensaje, el 1er byte de este campo contiene la parte baja de la dirección
y el segundo byte contiene la parte alta de la dirección, por lo tanto se puede tener
hasta 65535 direcciones. Dentro del mensaje son los bytes 5 y 6.

SOURCE Este campo utiliza 2 bytes y nos indican la dirección de la estación que esta
originando el mensaje, el 1er byte de este campo contiene la parte baja de la
dirección y el segundo byte contiene la parte alta de la dirección, por lo tanto se
puede tener hasta 65535 direcciones. Dentro del mensaje son los bytes 7 y 8.

USER DATA Contiene los blocks que siguen al “Header Block”, donde cada block es de 16 bytes
mas el CRC (Código de Redundancia Cíclica), excepto el último block que puede ser

AbelG Resumen Dnp3.0 Página 5 de 13

 menor dependiendo de la función solicitado. Estos blocks empiezan a partir del byte
11 en adelante.

CRC Este campo utiliza 2 bytes que son para el código de seguridad el cual se genera
para cada block y se agrega el CRC al final de cada block.

Reset Esta función se utiliza por ejemplo para habilitar la comunicación en una dirección
siendo de Primaria a Secundaria, otra uso es cuando lo envía la estación Primaria
cuando es la primera vez o bien después de 1 falla de comunicación (no responde la
UTR), también se usa para sincronizar el FCB entre la estación primaria y
secundaria.

FUNCIONES DE TRANSPORTE ( TRANSPORT FUNCTIONS )

Esta capa forma parte de “USER DATA”, es especifica únicamente para aquellos mensajes que son
mas grandes que un LPDU (Link Protocol Data Unit) entre la estación primaria y secundaria.

A continuación se observa el formato de esta capa formado por TH byte 11 dentro del mensaje y
User Data byte 12 en adelante.

TH USER DATA

TH Transport control octect – 1 octect in length

USER DATA 1 to 249 octets in length

El primer campo de esta capa es “Transport Header” TH, el cual contiene información para la
estación secundaria para reconstruir el mensaje completo. Donde la estación secundaria checa el TH
cada vez que recibe un LSDU (Link Service Data Unit), para la secuencia correcta y en base a esta
construir un TSDU (Transport Service Data Unit)..

El TH contiene información que indica si es el 1er Telegrama o último Telegrama y proporciona

para cada Telegrama un número de secuencia de 6 bits (0 a 3Fh).

Cuando una aplicación solicita la transmisión de mensajes largos, el mensaje es particionado en

fragmentos de 16 bytes dentro del USER DATA, siendo el número máximo de 249 bytes.

El campo de Transport Header utiliza un byte, a continuación se indica la información de los bits o
banderas utilizados en este byte.

SEQUENCE
FIN FIR

Bit 7 6 5 4 3 2 1 0

AbelG Resumen Dnp3.0 Página 6 de 13

FIN FINal bit, este bit se utiliza para indicar si es el último “telegrama”, de la función
solicitada, cuando una estación primaria transmite 1 mensaje a una estación
secundaria “Transport Function” particiona el mensaje en varios LSDUs, este
proceso agrega a la capa de transporte el byte “TH” al inicio de los datos de usuario
“User Data” que contienen la información para reconstruir el mensaje por la
estación secundaria. A continuación se indica el valor de este bit.

FIN=0 Indica que continúan mas mensajes, esto aplica cuando la función esta
solicitando mas de 249 bytes.
FIN=1 Indica que es el último telegrama, es decir son menos de 249 bytes los que se
están solicitando.

Nota. Si un mensaje es recibido si el bit FIR=1 y sin secuencia entonces el mensaje es

ignorado.

FIR FIRst bit este bit se utiliza para indicar cuando es el primer “telegrama”, de una
secuencia.

FIR=0 Indica que el telegrama no es el primero dentro de una secuencia

FIR=1 Indica que es el primer telegrama dentro de una secuencia.

SEQUENCE Este campo es utilizado para verificar que cada mensaje del mismo tipo no se pierda
o se duplique, el número de secuencia se incrementa en uno para cada mensaje que
es transmitido o recibido a la misma dirección. El número de secuencia varia entre 0
y 63 y es del tipo circular.

Ejemplo si se van a transmitir 598 bytes, entonces tenemos que el número máximo
que podemos transmitir por telegrama es 249 bytes, nos da como resultado 2
telegramas de 249 bytes y un tercero de 100 bytes, a continuación se muestra el
valor de los bits FIR, FIN y SÉQUENSE.
Envía los primeros 249 Envía los siguientes 249 Envía los últimos 100 bytes
bytes. bytes. FIR=0
FIR=1 FIR=0 FIN=1
FIN=0 FIN=0 SEQUENSE=4
SEQUENSE=2 SEQUENSE=3 USER DATA=2
USER DATA=0 USER DATA=1

APPLICATION PROTOCOL CONTROL INFORMATION “APCI”

AbelG Resumen Dnp3.0 Página 7 de 13

Esta se encuentra formado por dos formatos el de solicitud “Application Request Format” y el de
respuesta “Application Response Format”, los cuales controlan la secuencia y flujo de los mensajes
de aplicación entre la UTM y la UTR y los servicios de aplicación de la Unidad de Datos “ASDU” el
cual incluye DUIs y Data Object Headerds.

El formato de solicitud esta formado por 2 campos el de Aplicación “Application Control” y el de

Código de Función “Function Code” y el de respuesta por 3 campos que son el de Aplicación,
Código de Función y de Banderas, a continuación se muestran estos formatos.

Application Control Function Code

AC FC

Request Header

Application Control Function Code Internal Indications

AC FC IIN

Response Header

A continuación se indica el contenido de cada campo para “Request Header “.

APPLICATION Este campo esta formado por 1 byte, y se utiliza para reconstruir información
CONTROL cuando son varios telegramas, este campo esta integrado por 4 campos como se
observa a continuación.

SEQUENCE
FIN FIR CON

Bit 7 6 5 4 3 2 1 0

FIR Este bit si esta en 1 indica que es el primer fragmento de un mensaje de

aplicación.

FIN Este bit si esta en 1 indica que es el fragmento final de un mensaje de aplicación.

CON Este bit se utiliza para habilitar o deshabilitar la confirmación de mensajes, si

este bit esta en 1 en el mensaje que se recibe, indica que el transmisor estará
esperando la confirmación.

SEQUENSE este campo utiliza 5 bits (0- 1Fh) y es para indicar el número de
fragmento, si el valor se encuentra entre 0 y 15 indica son solicitudes de la

AbelG Resumen Dnp3.0 Página 8 de 13

 estación maestra y todas las UTRs responden, para valores del 16 al 31 son
reservados para respuestas no solicitadas (es un mensaje generado por una
UTR, usualmente contiene datos que son enviados automáticamente a la
maestra).

FUNCTION Este campo esta formado por 1 byte, y se utiliza para indicar la función que se está
CODE solicitando (lectura, selección, operación de punto de control, etc.) así como la
dirección del mensaje si es una solicitud o respuesta. Para respuesta los valores
permitidos son 0, 128 ó 129.

A continuación se muestra la tabla con los códigos de función así como su

descripción.

AbelG Resumen Dnp3.0 Página 9 de 13

 CODE FUNCTION DESCRIPTION
Transfer Function Codes
0 Confirm Message fragment confirmation used in both request
and responses. No response to this message is
required
1 Read Request specified objects from Outstation: response
with objects requested that are available
2 Write Store specified objects in Outstation: respond with
status of the operation
Control Function Codes
3 Select Select or arm output points but do not set or produce
any output action (controls, set points, analog
outputs); respond with the status of the control points
selected. The Operate function code is required to
activate these outputs.
4 Operate Set or produce the output action on the points
previously selected with the Select function: respond
with the status of the control points.
5 Direct Operate Select and set or operate the specified outputs:
respond with the status of the control points.
6 Dir4ect Operate Select an set or operate the specified outputs but do
No not send a response to the request.
Acknowledgement
Freeze Function Codes
7 Immediate Freeze Copy the specified objects to a freeze buffer and
respond with status of the operation
8 Immediate Freeze Copy the specified objects to a freeze buffer; do not
No respond with a message
Acknowledgement
Transfer Function Codes
9 Freeze and Clear Copy the specified objects to a freeze buffer, then clear
the objects; respond with the status of the operation
10 Freeze and Clear Copy the specified objects to a freeze buffer; then clear
No the objects; do not respond with a message
Acknowledgement
11 Freeze with Time Copy the specified objects to a freeze buffer at the
specified time and intervals; respond with the status of
the operation
12 Freeze with Time Copy the specified objects to a freeze buffer at the
No specified time and intervals; do not respond with a
Acknowledgement message
Application Control Function Codes
13 Cold Restart Perform the desired reset sequence; respond with a
time object indicating time till Outstation availability
14 Warm Restart Perform the desired partial reset sequence; respond
with a time object indicating time till Outstation
availability
15 Initialize Data to Initialize the specified data to power up initial values;
Defaults respond with status of the operation
16 Initialize Application Ready the specified application(s) to run; respond
with status of the operation
17 Start Application Start running the specified application(s); respond
with status of the operation
18 Stop Application Stop the specified application(s); respond with status
of the operation

AbelG Resumen Dnp3.0 Página 10 de 13

 CODE FUNCTION DESCRIPTION
Configuration Function Codes
19 Save Configuration Save the specified configuration to non-volatile
memory; respond with a time object indicating time
till Outstation availability.
20 Enable Unsolicited Enables spontaneous reporting of the specified data
Messages object(s); respond with status of the operation
21 Disable Unsolicited Disable spontaneous reporting of the specified data
Messages object(s); respond with status of the operation
22 Assign Class Assigned specified data object(s) to a particular class
Time Synchronization Function Codes
23 Delay Measurement Allows the application to calculate the path delay (or
propagation delay) for a particular Outstation. The
value calculated from this function code should be
used to adjust the time of day when setting the
Outstation time.
Reserved
24-120 Reserved for future use
121-128 Reserved for future use
Respond Function Codes
0 Confirm Message fragment confirmation used in both requests
and responses. No response to this message is
required.
129 Response Response to a request message
130 Unsolicited Message Unsolicited response that was not prompted by
request.

A continuación se indica el contenido de “Response Header “

De la imagen Response Header observamos que está formado por los campos de “Application
Control” , “Function Code” y “Internal Indications”

La información para los 2 primeros campos “Application Control” , “Function Code” es la misma
que se describió en “Request Header “, a continuación se describe el uso del tercer campo “Internal
Indications”.

INTERNAL Este campo esta formado por 2 bytes, y la información contenida se refiere al estado
INDICATION de las banderas, estas banderas solo aplican en el mensaje de respuesta.

First Octet Second Octet

De estos 2 bytes se usan 14 bits para banderas, el bit 6 y 7 del segundo byte están reservadas
para uso futuro. Para ver el significado de cada bit referirse al manual de DNP3 sección
“Application Layer” apartado “Internal Indication”.

Después de “Application Header” continua “Object Header” el cual especifica los objetos de datos
que están contenidos en el mensaje o que van a ser usados para respuesta. Este esta formado por 3
campos como se indica a continuación y que son los mismos para solicitud y respuesta.

AbelG Resumen Dnp3.0 Página 11 de 13

 Object Qualifier Range

Object Header

OBJECT Este campo esta formado por 2 bytes, y la información contenida se refiere al grupo
y variación del objeto.

0 or Object variation Application request direction

Object Group
Object variation Application response direction

The Object Field

Es aquí donde se indica la información o tipo de mensaje que se va a solicitar a la

UTR, en el 1er byte se indica el objeto o grupo (tipo de datos ejemplo leer entradas
analógicas) y en el 2do byte se indica la variación (por ejemplo sí es de 16 o 32 bits).

A continuación se muestra algunos ejemplos de objeto y variación.

Objeto Variación Descripción

30(1Eh) 02 Entrada analógica de 16 bits
01 01 Entrada digital de 1 bit
12(0Ch) 01 Salida Digital de Control

QUALIFIER Este campo esta formado por 1 byte, y la información contenida en este byte indica
como será interpretado el campo Rango. Este byte esta formado a su vez por 3
campos como se observa a continuación

Index Size 4 bit Qualifier Code

R

Bit 7 6 5 4 3 2 1 0

The Qualifier Field

A continuación se describe cada campo.

R. Este bit no se usa, siempre esta en cero

Index Size. Este campo es de 3 bits y dependiendo de su contenido indicará el

tamaño en bytes de cada punto de entrada en el campo rango. Cuando en el
campo Qualifier se especifica inicio y fin, este campo Index Size puede tomar
el valor de 1, 2 ó 3, en este caso el campo rango especifica la cantidad de

AbelG Resumen Dnp3.0 Página 12 de 13

 objetos e índices que siguen al campo rango Si Index Size =0 entonces el
campo rango especifica la cantidad de objetos empezando de 0 al valor
indicado en rango –1.

Qualifier Code. Este campo es de 4 bits y se utiliza para especificar el contenido del
campo rango. Para valores de 0, 1 y 2 el rango de inicio y final son
considerados como índices de datos, para valores de 3, 4 y 5 los rangos son
interpretados como direcciones de memoria virtual y para valores 7, 8 y 9
son usados para indicar que el campo rango consiste de un contador
indicando el número de objetos en cuestión.

A continuación se indica el valor de este campo y su significado.

Valor Descripción
0 Usa 8 bits para indicar rango de inicio y fin.
1 Usa 16 bits para indicar rango de inicio y fin
2 Usa 32 bits para indicar rango de inicio y fin
3 Usa 8 bits para indicar una dirección
4 Usa 16 bits para indicar una dirección
5 Usa 32 bits para indicar una dirección
6 EL TAMAÑO DEL RANGO ES 0 implica todos los puntos
7 Usa 8 bits para indicar la cantidad de objetos
8 Usa 16 bits para indicar la cantidad de objetos
9 Usa 32 bits para indicar la cantidad de objetos

RANGE Este campo esta en función del valor de Index Size y de Qualifier, el cual puede estar
formado de 0 hasta 8 bytes. Por ejemplo si el valor del campo Qualifier esta entre 0
y 5 el campo rango tendrá 2 subcampos indicando rango de inicio y rango final que
se utiliza para definir un rango de objetos, los cuales siguen después del Object
Header.

AbelG Resumen Dnp3.0 Página 13 de 13