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:
DNP
Direccionar hasta 65000 dispositivos Direccionar hasta 4,000,000,000 puntos 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.
EPA
Physical Layer Data Link Layer Application Layer
A continuación se indica los servicios de cada una de las capas utilizadas en el protocolo DNP3
Capa Física
Capa de Enlace de Datos
AbelG
Convierte octetos a datos seriales (bits) Proporciona las señales de control para el medio de comunicación 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 Agrega el encabezado y CRC (Código de Redundancia Cíclica) a los mensajes de la capa de aplicación Provee servicios de SEND-CONFIRM, SEND-NO REPLY, REQUEST-RESPONSE Mensajes de longitud variable
Resumen Dnp3.0
Página 2 de 13
Capa de A licación
Es la mas alta define por ejemplo la función del mensaje (ejemplo leer entradas analógicas) 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 START 0X05
START 0X64
LENGTH
CONTROL
Block1
DESTINATION
SOURCE
CRC
USER DATA
Block n
CRC
USER DATA
CRC
Body
Fixed Length Header 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:
DIR
1 PRIM 0
FCB
FCV
Primary to Secondary FUNCTION CODE
RES
DFC
Secondary to Primary
Bit 7 6 5 4
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 SENDCONFIRM 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 Code 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Frame Type SEND-CONFIRM expected SEND-CONFIRM expected SEND-CONFIRM expected SEND-CONFIRM expected SEND-NO REPLY expected REQUEST-RESPON expected
Service Function RESET of remote link Reset of user process TEST function for link User data Unconfirmed User Data Not Used Not Used Not Used Not Used REQUEST LINK STATUS Not Used Not Used Not Used Not Used Not Used Not Used
FCV Bit 0 0 1 1 0 0 -
Function Code Field of the Control Octect Sent from the Secondary Station (PRM=0) Function Code 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Frame Type CONFIRM CONFIRM RESPOND
Service Function ACK positive acknowledgement NACK Message not accepted, link busy Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Status of Link (DFC=0 or DFC=1) Not Used Not Used Link service not functioning 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
TH USER DATA
USER DATA
Transport control octect – 1 octect in length 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.
FIN
FIR
SEQUENCE
Bit 7 6 5 4 3
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 bytes. FIR=1 FIN=0 SEQUENSE=2 USER DATA=0
Envía los siguientes 249 bytes. FIR=0 FIN=0 SEQUENSE=3 USER DATA=1
Envía los últimos 100 bytes FIR=0 FIN=1 SEQUENSE=4 USER DATA=2
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 AC
Function Code FC
Request Header
Application Control AC
Function Code FC
Internal Indications 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.
FIN
FIR
CON
SEQUENCE
Bit 7 6 5 4 3 2
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 CODE
Este campo esta formado por 1 byte, y se utiliza para indicar la función que se está 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 Transfer Function Codes 0 Confirm
1
Read
2
Write
DESCRIPTION
Message fragment confirmation used in both request and responses. No response to this message is required Request specified objects from Outstation: response with objects requested that are available Store specified objects in Outstation: respond with status of the operation
Control Function Codes 3
Select
4
Operate
5
Direct Operate
6
Dir4ect Operate No Acknowledgement
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. Set or produce the output action on the points previously selected with the Select function: respond with the status of the control points. Select and set or operate the specified outputs: respond with the status of the control points. Select an set or operate the specified outputs but do not send a response to the request.
Freeze Function Codes 7 8
Immediate Freeze
Copy the specified objects to a freeze buffer and respond with status of the operation 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
10
Freeze and Clear No Acknowledgement Freeze with Time
11
12
Freeze with Time No Acknowledgement
Copy the specified objects to a freeze buffer, then clear the objects; respond with the status of the operation Copy the specified objects to a freeze buffer; then clear the objects; do not respond with a message Copy the specified objects to a freeze buffer at the specified time and intervals; respond with the status of the operation Copy the specified objects to a freeze buffer at the specified time and intervals; do not respond with a message
Application Control Function Codes 13 14
15 16 17 18
AbelG
Cold Restart
Perform the desired reset sequence; respond with a time object indicating time till Outstation availability Warm Restart Perform the desired partial reset sequence; respond with a time object indicating time till Outstation availability Initialize Data to Initialize the specified data to power up initial values; Defaults respond with status of the operation Initialize Application Ready the specified application(s) to run; respond with status of the operation Start Application Start running the specified application(s); respond with status of the operation Stop Application Stop the specified application(s); respond with status of the operation
Resumen Dnp3.0
Página 10 de 13
CODE
FUNCTION
DESCRIPTION
Configuration Function Codes 19
20 21 22
Save Configuration
Save the specified configuration to non-volatile memory; respond with a time object indicating time till Outstation availability. Enable Unsolicited Enables spontaneous reporting of the specified data Messages object(s); respond with status of the operation Disable Unsolicited Disable spontaneous reporting of the specified data Messages object(s); respond with status of the operation 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
Reserved for future use Reserved for future use
24-120 121-128
Respond Function Codes 0
129 130
Confirm
Message fragment confirmation used in both requests and responses. No response to this message is required. Response Response to a request message 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 INDICATION
Este campo esta formado por 2 bytes, y la información contenida se refiere al estado 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 variation
Application response direction
Object Group
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 30(1Eh) 01 12(0Ch)
QUALIFIER
Variación 02 01 01
Descripción Entrada analógica de 16 bits Entrada digital de 1 bit Salida Digital de Control
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
R
Index Size
4 bit Qualifier Code
Bit 7 6 5 4 3
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 0 1 2 3 4 5 6 7 8 9
RANGE
AbelG
Descripción Usa 8 bits para indicar rango de inicio y fin. Usa 16 bits para indicar rango de inicio y fin Usa 32 bits para indicar rango de inicio y fin Usa 8 bits para indicar una dirección Usa 16 bits para indicar una dirección Usa 32 bits para indicar una dirección EL TAMAÑO DEL RANGO ES 0 implica todos los puntos Usa 8 bits para indicar la cantidad de objetos Usa 16 bits para indicar la cantidad de objetos Usa 32 bits para indicar la cantidad de objetos
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.
Resumen Dnp3.0
Página 13 de 13
