CAPACITACIÓN EN EL PROTOCOLO DNP3


La capacitación en el protocolo DNP3 permite conocer a fondo la estructura del protocolo, los métodos de comunicación y los tipos de datos disponibles, lo cual es de gran ayuda para identificar problemas.

El personal que realice la capacitación en DNP3 podrá analizar y entender una trama de comunicación.

PRACTICAS PARA EL CURSO DE CAPACITACIÓN EN DNP3

Se realizan prácticas enfocadas a la configuración del protocolo en los equipos de la plataforma de pruebas y en el análisis de tramas.

En las prácticas de configuración, se explican cada uno de los parámetros del protocolo DNP3 en base a la teoría enseñada y en las prácticas de análisis se tramas, se observan los datos enviados y recibidos entre los relés de protección, el Gateway, el SCADA y los simuladores de protocolos.

La plataforma de pruebas usado para el curso de capacitación en DNP3 se observa en la siguiente imagen:

training

El simulador de protocolos usado en el curso del protocolo DNP3 , es Axon Test , este simulador y otros simuladores de pruebas se instalan en los portátiles de los participantes, estos paquetes software son sistemas Maestros/Clientes de los relés de protección, es decir se conectan a los relés para enviar y recibir información.

Los simuladores también cuentan con protocolos Esclavo/Servidor, para enviar y recibir información con el SCADA y el Gateway de subestación.

Se dispone de un Switch para conectar los relés de protección, Gateway, SCADA y los portátiles de los participantes.

El Gateway usado para el curso es Axon Exchange y el SCADA es Axon Builder , los cuales son Maestros/Clientes de los relés de protección y de los simuladores, de esa forma el curso cuenta con varios sistemas, que permiten lograr el objetivo deseado.

 1. ESTRUCTURA DEL PROTOCOLO.

2. FORMATOS DE TRAMAS DE TRANSMISIÓN.

2.1. FORMATO DE TRAMA.

2.2. ESTRUCTURA GENERAL DE DATOS DE APLICACIÓN.

3. DESCRIPCIÓN Y SIGNIFICADO PARA LA CONFIGURACIÓN DE PARAMETROS DEL PROTOCOLO.

3.1. LINK ADDRESS.

3.2. CLASES 0, 1, 2, 3.

3.3. SOLICITADOS NO SOLICITADOS.

4.  DIFERENCIA ENTRE UN DNP3 RTU Y DNP3 LAN/WAN

5. ESTAMPA DE TEMPO EN PROTOCOLO DNP3

6. PRÁCTICAS

1. INTRODUCCIÓN
 
2. ESTRUCTURA DEL PROTOCOLO.
2.1. CAPA FÍSICA
2.2. CAPA DE ENLACE DE DATOS
2.3  CAPA DE TRANSPORTE (PSEUDO-TRANSPORTE)
2.4. CAPA DE APLICACIÓN MANEJO DEL MENSAJE
2.5. PROCEDIMIENTOS DE TRANSMISIÓN.
 
3. FORMATOS DE TRAMAS DE TRANSMISIÓN.
3.1. FORMATO DE TRAMA.
3.2. ESTRUCTURA GENERAL DE DATOS DE APLICACIÓN.
3.2.1. FUNCIONES DEL MENSAJE EN LA CAPA DE APLICACIÓN
3.2.2. BIBLIOTECA DE OBJETOS
3.2.2.1. DEFINICIÓN DE OBJETOS DIGITALES
3.2.2.2. DEFINICIÓN DE OBJETOS ANALOGOS
3.2.2.3. DEFINICIÓN DE OBJETOS CONTADORES
3.2.2.4. DEFINICIÓN DE OBJETOS DE TIEMPO
3.2.2.5. DEFINICIÓN DE OBJETOS PARA MANEJAR CLASES
3.2.3. CÓDIGOS DE CUALIFICADOR E INDEXADO
3.2.4. SINCRONIZACIÓN DE TIEMPO
3.2.5. FUNCIONES DE CONTROL
 
4. DESCRIPCIÓN Y SIGNIFICADO PARA LA CONFIGURACIÓN DE PARAMETROS DEL PROTOCOLO
4.1. LINK ADDRESS.
4.2. CLASES 0, 1, 2, 3.
4.3. SOLICITADOS NO SOLICITADOS.

RESUMEN DEL PROTOCOLO DNP3


Historia

DNP fue creado originalmente por Westronic, Inc. (ahora GE Harris) en 1990. En 1993, el set de documentos de especificación del protocolo "DNP 3.0 Basic 4" cobró dominio público. La propiedad del protocolo fue entregada al recientemente formado DNP Users Group en octubre de ese año. Desde entonces, el protocolo ha ganado aceptación mundial, incluyendo la formación de grupos de usuarios en China, América latina, y Australia.

En enero de 1995, fue formado el DNP Technical Committee para estudiar mejoras y recomendarlas para su aprobación al Users Group general. Una de las tareas más importantes de este cuerpo era publicar el documento DNP Subset Definitions, que establece los estándares para las puestas en marcha de DNP 3.0.

DNP 3.0 es un protocolo para sistemas SCADA moderno, abierto, inteligente, robusto y eficiente. Entre otras cosas, puede:

  • Solicitar y responder con múltiples tipos de datos en un solo mensaje.
  • Segmentar mensajes en múltiples frames para asegurar excelente detección y recuperación de errores.
  • Incluir en una sola respuesta datos cambiados.
  • Asignar prioridad a los ítems de datos y solicitarlos periódicamente basado en su prioridad.
  • Responder sin solicitud previa.
  • Utilizar sincronización de tiempo y con un formato estándar.
  • Permitir múltiples operaciones punto a punto y al master.
  • Permitir objetos definibles por el usuario incluyendo transferencia de archivos.

 

ARQUITECTURA EN CAPAS

DNP 3.0 es un protocolo de capas. Aún así, en lugar de asemejarse al protocolo de 7 capas de la OSI (Open System Interconection − interconexión de sistemas abiertos), DNP 3.0 adhiere a un estándar simplificado de 3 capas propuesto por el IEC (International Electrotechnical Commission − Comisión internacional de Electrotecnia) para implementaciones más básicas. El IEC llama a esto Enhanced Performance Architecture, o EPA. (En realidad, sin embargo, DNP 3.0 agrega una cuarta capa, una capa de pseudo−transporte que permite la segmentación del mensaje).

La estructuración en capas o niveles, sigue el siguiente esquema:

  • Los mensajes a nivel de aplicación son denominados Fragmentos. El tamaño máximo de un fragmento está establecido en 2048 bytes.
  • Los mensajes a nivel de transporte son denominados Segmentos.
  • Los mensajes a nivel de enlace son denominados Tramas. El tamaño máximo de una trama DNP3 es de 292 bytes.

Cuando se transmiten datos, estos sufren las siguientes transformaciones al pasar por las diferentes capas:

  • Los datos se encapsulan en fragmentos a nivel de aplicación.
  • El nivel de transporte es el encargado de adaptar los Fragmentos para poder encapsularlos en tramas (nivel de enlace), para lo cual, secciona el mensaje del nivel de aplicación si es necesario, y les agrega la cabecera de transporte, formando de este modo los segmentos.
  • En el nivel de enlace, los segmentos recibidos del nivel de transporte son empaquetados en tramas, para lo cual se les añade a estos una cabecera de enlace, y además, cada 16 bytes un CRC de 2 bytes.

Cuando se reciben datos, las transformaciones se hacen de la siguiente forma:

  • El nivel de enlace se encarga de extraer las tramas recibidas los segmentos que son pasados al nivel de transporte.
  • El nivel de transporte lee la cabecera de los segmentos recibidos del nivel de enlace, y con la información obtenida extrae y compone los fragmentos que serán pasados al nivel de aplicación.
  • En el nivel de aplicación los fragmentos son analizados y los datos son procesados según el modelo de objetos definido por las especificaciones del estándar.
Capa Física

La capa física se refiere sobre todo a los medios físicos sobre los cuales se está comunicando el protocolo. Por ejemplo, maneja el estado del medio (libre u ocupado), y la sincronización a través del medio (iniciando y parando). Más comúnmente, DNP se especifica sobre una capa física serial simple tal como RS−232 o RS−485 usando medios físicos tales como fibra, radio o satélite. Los proyectos se orientan actualmente para implementar DNP sobre una capa física Ethernet.

Capa de Transmisión De Datos

La capa de transmisión de datos maneja la conexión lógica entre el remitente y el receptor de la información y pone a prueba las características de error del canal físico. DNP logra esto comenzando cada frame de transmisión de datos con una cabecera, e insertando un CRC de 16 bits cada 16 bytes del frame. Un frame es una porción de un mensaje completo comunicado sobre la capa física. La medida máxima de un frame de transmisión de datos es 256 bytes. Cada frame tiene una dirección fuente de 16 bits y una dirección de destino también de 16 bits, las que pueden ser una dirección de difusión o broadcast (0xffff). La información del direccionamiento, junto con un código de inicio de 16 bits, la longitud del frame, y un byte de control de transmisión de datos se hallan en la cabecera (10 bytes) de transmisión de datos.

El byte de control de transmisión de datos indica el propósito del frame de transmisión de datos, y el estado de la conexión lógica. Los valores posibles del byte de control de transmisión de datos son: ACK, NACK, la conexión necesita resetear, la conexión ha sido reseteada, confirmación de solicitud de transmisión de datos del frame, solicitud de estado de conexión, y contestación de estado de conexión. Cuando se solicita una confirmación de transmisión de datos, el receptor debe responder con un frame ACK de transmisión de datos si el mismo es recibido y pasa los controles del CRC. Si una confirmación de la transmisión de datos no se solicita, no se requiere ninguna respuesta de la transmisión de datos.

mod14

  • 2 bytes de inicio (start bytes), cuyo valor es fijo. 0x05 (valor en hexadecimal) para el primero y 0x64 para el segundo.
  • 1 byte con el tamaño de la trama. Este valor no tiene en cuenta ni la cabecera, ni los CRC.
  • 1 byte con el código de control, que permite fijar los servicios del nivel de enlace, el sentido del flujo, etc.
  • 2 bytes con la dirección de destino, codificada en big-endian.
  • 2 bytes con la dirección de origen, codificada en big-endian.
  • 2 bytes de CRC.
Capa de Pseudo−Transporte

La capa de pseudo−transporte divide mensajes de la capa de aplicación en múltiples frames de transmisión de datos. Para cada frame, inserta un código de función de 1 byte que indica si el frame de transmisión de datos es el primer frame del mensaje, el último frame del mensaje, o ambos (para mensajes singles). El código de función también incluye un número de secuencia del frame que se incrementa con cada uno y permite que la capa de transporte recipiente detecte frames perdidos.

mod15

Capa de Aplicación

La capa de aplicación responde a mensajes completos recibidos (y arribados de la capa de transporte), y construye los mensajes basados en la necesidad o la disponibilidad de los datos del usuario. Una vez que se construyan los mensajes, se pasan a la capa de pseudo−transporte donde se dividen en segmentos y se pasan a la capa de transmisión de datos y eventualmente comunicados sobre la capa física.

Cuando los datos a transmitir son demasiado grandes para un solo mensaje de la capa de aplicación, se pueden construir mensajes múltiples de la capa de aplicación y transmitirlos secuencialmente. Sin embargo, cada mensaje es un mensaje independiente de la capa de aplicación; existe una indicación de su asociación con el siguiente, en todos excepto en el último. Debido a esta posible fragmentación de los datos de aplicación, cada mensaje es referido como un fragmento, y un mensaje por ende puede ser un mensaje de un solo fragmento o un mensaje de múltiples fragmentos.

Los fragmentos de la capa de aplicación de las estaciones Master de DNP son típicamente solicitudes de operaciones sobre objetos de datos, y los fragmentos de la capa de aplicación de estaciones esclavas de DNP son típicamente respuestas a esas peticiones. Una estación esclava DNP puede también transmitir un mensaje sin una petición (una respuesta no solicitada).

Como en la capa de transmisión de datos, los fragmentos de la capa de aplicación se pueden enviar con una solicitud de confirmación. Una confirmación de la capa de aplicación indica que un mensaje no sólo ha sido recibido, sino también analizado sin error. (por otra parte, una confirmación de la capa de transmisión de datos, o ACK, indica solamente que se ha recibido el frame de la transmisión de datos y que pasó los controles de error del CRC.)

Cada fragmento de la capa de aplicación comienza con una cabecera seguida por una o más combinaciones de objetos de datos y objetos cabecera. La cabecera de la capa de aplicación contiene un código de control de la aplicación y un código de función de la aplicación. El código de control de la aplicación contiene una indicación de si el fragmento es parte de un mensaje multi−fragmento, una indicación de si una confirmación de la capa de aplicación es requerida por el fragmento, una indicación de si el fragmento fue no solicitado, y contiene un número de secuencia de la capa de aplicación. Este número de secuencia de la capa de aplicación permite que la capa de aplicación receptora detecte los fragmentos que están fuera de secuencia, o los fragmentos perdidos.

El código de función de cabecera de la capa de aplicación indica el propósito, o la operación solicitada, del mensaje. A la par que DNP 3.0 permite múltiples tipos de datos dentro de un único mensaje, permite una única operación sobre los tipos de datos dentro del mismo. Algunos ejemplos de códigos de función son:

Confirmar (para las confirmaciones de la capa de aplicación), leer y escribir, seleccionar y operar, congelar y limpiar (para los contadores), reiniciar, permitir e invalidar mensajes no solicitados, y asignar la clase (discutida abajo). El código de función de cabecera de la capa de aplicación se aplica a todas las cabeceras del objeto, y por lo tanto a todos los datos dentro del fragmento del mensaje.

mod16

mod17

Organización de la Base de datos

En DNP, los datos se ordenan en tipos de datos. Cada tipo de datos es un grupo objeto, incluyendo:

  • Entradas de información binaria (valores de un solo bit sólo lectura).
  • Salidas binarias (valores de un solo bit cuyo estado puede ser leído, o que puede ser pulsado o trabado directamente o a través de operaciones tipo sbo).
  • Entradas de información analógicas (valores múltiple−dígito sólo lectura).
  • Salida analógica (valor múltiple−dígito cuyo estado puede ser leído, o que puede ser controlado
  • Directamente o a través de operaciones tipo sbo).
  • Contadores.
  • Hora y fecha.
  • Objetos de transferencia de archivos.
  • Etc.

mod18

Para cada grupo de objetos, o tipo de datos, existen uno o más puntos de referencia. Un punto de referencia es un único valor del tipo especificado por su grupo de objeto.

También dentro de cada grupo de objeto, existen variaciones. Una variación del grupo de objeto se utiliza típicamente para indicar un método diferente de especificar datos dentro del grupo de objeto. Por ejemplo, las variaciones de entradas de información analógicas permiten la transferencia de los datos como valores enteros con signo de 16 bits, de 32 bits, o como valores de 32−bit con coma flotante.

Según lo descrito arriba, un mensaje de la capa de aplicación puede contener múltiples cabeceras del objeto.

Una cabecera del objeto especifica un grupo de objeto, una variación del grupo de objeto, y un rango de puntos dentro de esa variación del grupo de objeto. Algunos códigos de función de la cabecera de la capa de aplicación indican que a cada cabecera del objeto siguen los datos del mismo; otros códigos de función indican que no hay datos del objeto en el mensaje − en su lugar, múltiples cabeceras del objeto, si existen, siguen contiguamente a cada una de las otras. Por ejemplo, un fragmento leído del mensaje de solicitud contiene solamente las cabeceras del objeto que describen los grupos de objeto, las variaciones, y los rangos de puntos que se solicitan leer y responder; un fragmento leído del mensaje de respuesta contiene cabeceras del objeto y los datos del objeto solicitado.
DNP 3.0 permite que los object point ranges sean especificados en una variedad de maneras. Para petición de mensajes, los object point ranges pueden consistir en:

  • Una petición para todos los puntos del grupo de objetos especificado
  • Una petición para un rango contiguo de puntos comenzando con un específico punto de partida y
  • Terminando con un específico punto de llegada.
  • Una petición para una máxima cantidad de puntos con una lista de puntos solicitados.

Para los mensajes de respuesta, los object point ranges consisten típicamente en un rango contiguo de puntos que comienzan con un punto de partida especificado y terminan con una punto de llegada especificado, o con una lista de puntos. Para los object point ranges de respuesta que consisten en una lista de puntos, un número de punto precede a cada objeto de datos. El número de puntos en la lista se especifica como parte del object point range.

Modelo de Reportes

Muchos de los grupos de objeto pueden corresponder, pero se separan, los grupos de objeto que contienen datos del cambio. Los datos del cambio representan solamente los puntos que han cambiado para un grupo de objeto específicamente correspondiente. Por ejemplo, el grupo número 1 de objeto representa las entradas de información binarias (consideradas los datos estáticos), y el grupo número 2 de objeto representa datos binarios con cambio de la entrada de información. Cuando un punto en el grupo de objeto 1 se detecta que ha cambiado, un acontecimiento de cambio en el grupo de objeto 2 para el mismo número del punto se crea. Incluye solamente los puntos que han cambiado en los mensajes de respuesta, esto permite mensajes más pequeños y eficientes.

mod19

mod20