6

CONSIDERACIONES AVANZADAS DEL

PROTOCOLO DE RED DISTRIBUIDA

Objetivos

Cuando haya completado el estudio de este capítulo, podrá:

 Describir las definiciones del subconjunto DNP3

 Describir cómo se logra la interoperabilidad entre dispositivos DNP3
 Describir los procedimientos de prueba de conformidad DNP3
 Describir la sincronización de tiempo DNP3
 Describir el funcionamiento de DNP3 sobre TCP / IP y UDP / IP

6.1 DNP3 subconjunto definiciones

6.1.1 Niveles de implementación

Para obtener la interoperabilidad entre las versiones de un protocolo de diferentes fabricantes, es

necesario garantizar que todas las implementaciones de los fabricantes admitan los mismos
objetos y funciones de datos. Sin embargo, requerir que todos los fabricantes admitan todos los
objetos y funciones de datos no sería muy eficiente. Por ejemplo, un pequeño artefacto explosivo
improvisado tal como un reenganche montado en poste solo requeriría un pequeño subconjunto
de los tipos de objetos de datos disponibles, mientras que la interfaz RTU con varios dispositivos
podría requerir más. En DNP3, estos problemas se abordan a través de la definición de niveles de
subconjuntos.

Actualmente hay tres niveles de subconjuntos definidos en DNP3. Estos están designados en el
formato Nivel x’ de protocolo de capa de aplicación DNP3', o simplemente abreviado como
DNP3-L1, L2 o L3. Los niveles se describen en la tabla a continuación.

1
 Nivel 1 El nivel es el nivel más simple de implementación de DNP. Está destinado a
ser utilizado entre una estación maestra o un dispositivo intermedio, como un
concentrador de datos, y un pequeño dispositivo de extremo LED. Esto podría
ser un relé, un medidor o un controlador autónomo de algún tipo.
Normalmente, las entradas y salidas son locales para el dispositivo. Los
ejemplos de dispositivos pequeños incluyen medidores, relés, reconectores
automáticos o controladores de banco de condensadores.
Nivel 2 El Nivel 2 define un subconjunto más grande de características DNP que el
Nivel 1. Está destinado a ser utilizado entre una estación maestra o un
concentrador de datos, y una RTU o un IED grande. Normalmente, las
entradas y salidas son locales para el dispositivo.

Nivel 3 El nivel 3 define el subconjunto más grande de características DNP. No

requiere compatibilidad con todas las características posibles de DNP, pero
cubre la mayoría de las funciones requeridas con más frecuencia. Esto se
implementa típicamente entre una estación maestra y una RTU más grande o
más avanzada. Las entradas y salidas de los dispositivos del Subconjunto
Nivel 3 normalmente serían tanto remotas como locales.

6.1.2 Tablas de implementación

Los subconjuntos se definen enumerando los objetos de datos específicos que se deben manejar
y las operaciones que se realizarán en ellos, para cada nivel. Estos requisitos se establecen en una
tabla que muestra, para cada tipo de objeto de datos, los códigos de función y los valores de campo
calificador que deben ser admitidos por el maestro y el esclavo en ese nivel. La tabla se conoce
como una tabla de implementación. Las tablas de implementación se proporcionan en la
definición del subconjunto DNP3 para cada uno de los niveles 1, 2 y 3. A continuación se muestra
una tabla de implementación de ejemplo, con una entrada para ilustrar el significado.

La entrada de la tabla de ejemplo de nivel 2 que se muestra indica lo siguiente:

•El esclavo debe entender y responder a una solicitud de lectura (código de función 1)
•El esclavo debe ser capaz de responder a los índices de 8 bits o 16 bits en el campo de
rango
• (Q-código 0 y 1)
• El esclavo debe ser capaz de responder a la solicitud de todos los objetos (código Q 6)
• El esclavo debe ser capaz de proporcionar respuestas (129) y respuestas no solicitadas
• (130) según lo solicitado, utilizando índices de 8 bits o 16 bits en el campo de rango
Algunos otros aspectos que vale la pena mencionar sobre la mesa son:

• Para cada objeto de datos puede haber solicitud y una entrada de columna de respuesta
• Estos corresponden a mensajes de maestro y esclavo
• Los mensajes de solicitud son emitidos por el maestro y analizados por el esclavo
• Los mensajes de respuesta son emitidos por el esclavo y analizados por el maestro

2
 • El código de función se da en decimal
• Los códigos de campo del calificador se dan en hexadecimal (esto los presenta
directamente como I-tamaño, Q-código)
Curiosamente, la tabla de implementación de nivel 1 no incluye la capacidad de leer una entrada
binaria como se muestra en este ejemplo. La falta de esta función bastante básica ilustra el
concepto subyacente de que la interrogación por clase en lugar de llamar a tipos de objetos
específicos está destinada a ser utilizada en los niveles de implementación más bajos.

Al final de esta sección, se incluye una tabla completa de implementación de subconjuntos que
muestra los requisitos para cada uno de los niveles 1, 2 y 3. Por comodidad, estos se combinaron
en una sola tabla que muestra los tres niveles. En la documentación de DNP3, se muestran tablas
separadas para cada nivel.

6.1.3 Resumen de los subconjuntos de implementación

En esta subsección, los subconjuntos se describen en términos de las principales funciones

definidas para cada nivel.

Nivel 1 definición del subconjunto

Funciones esclavas de nivel 1:

• Lectura de objetos de datos de clase
• Lee de salida binaria y objetos de datos de salida analógica
• Controle las operaciones a los objetos de datos de salida binaria y de salida analógica
• Escribir para reiniciar bit de indicación interna
• Reinicio en frío
• Medida de retardo
• Tiempo de escritura
Funciones maestras de nivel 1:
• Aceptar los siguientes tipos de objetos de datos
• Entradas y eventos binarios
• Contadores y eventos contrarios
• Entradas y eventos analógicos
• Estado de salida binaria y analógica

Aunque un maestro L1 debe analizar muchos objetos, no se requiere un esclavo L1 para

generarlos. Esto es lógico cuando se considera que un maestro puede comunicarse con un gran
número de esclavos diferentes, por lo que necesitará una gran variedad de funciones.

Un esclavo puede enviar respuestas no solicitadas, pero debe ser configurable desactivado. El
nivel 1 incluye soporte completo de referencia de objetos de clase, que es quizás la forma más
sencilla de solicitar objetos, y se requiere que sea totalmente compatible con todos los niveles. La
tabla de implementación muestra que los objetos de clase 0 pueden referenciarse usando el
calificador 06, que es el modo de todos los objetos. Las clases 1 a 3 pueden referenciarse
utilizando los calificadores 06, 07 o 08. Las últimas dos permiten convocar una cantidad limitada
de eventos a la vez.

3
Nivel 2 definición de subconjunto

Funciones esclavas de nivel 2 - adicionales al nivel 1:

 Acepta solicitudes de congelación en objetos de contador binarios

 Solicitudes de lectura de parses para la variación 0 (todas las variaciones) para algunos
objetos
 Solicitudes de lectura de parses para las variaciones 1, 2 y 3 de objetos de cambio
binarios
 Analiza y puede responder a las solicitudes de objetos de contador congelados
 Puede enviar respuestas no solicitadas que contienen datos estáticos

Funciones maestras de nivel 2 - sin extensiones al nivel 1

Definición de subconjunto de nivel 3

Funciones de nivel 3: adicionales a los niveles 1 y 2:

• Slave procesará solicitudes de lectura para muchos objetos específicos y variaciones

• Admite una mayor gama de solicitudes y códigos de funciones
• Habilitar y deshabilitar respuestas no solicitadas clase por clase
• Por ejemplo, procesará lo siguiente:
– Clase 1 (objeto 60, var 2, calificador 6)
– Clase 2 (objeto 60, var 3, calificador 6)
– Clase 3 (objeto 60, var 4, calificador 6)
• Asignación dinámica de objetos de datos a las clases

Referencia rápida del campo calificador

Los significados de los códigos de campo del calificador de funciones se presentaron en un

capítulo anterior, mostrando el tamaño del índice y los subcampos calificadores por separado. El
lector recordará que estos están estructurados de la siguiente manera:

Campo calificador

En las tablas de implementación, los valores del campo del calificador se muestran simplemente
como un valor hexadecimal de dos dígitos, a partir del cual los valores del tamaño I y del código
Q se pueden leer directamente. El lector pronto notará que solo ciertas combinaciones de estos
aparecen en las tablas de implementación. Por lo tanto, es conveniente tener una tabla de
"referencia rápida" para estas combinaciones. Esto se muestra a continuación.

4
Esta tabla muestra que, para los subconjuntos definidos, solo se usa una pequeña cantidad de
métodos para hacer referencia a los datos. Estos son:

• Modo de índice de rango, donde el campo de rango tiene los valores de índice de inicio y
detención
• Modo sin rangos sin índices, donde el campo del rango tiene la cantidad de objetos de
datos. En una respuesta, los objetos de datos simplemente se anexan
• Modo no incluido con índices. Aquí es donde los objetos de datos no están en un orden
consecutivo, y cada uno requiere su propia referencia de índice
• Modo de todos los objetos, que se usa en una solicitud solo para referirse a todos los
objetos del grupo

6.1.4 Referencia rápida del código de función

Los códigos de función se proporcionaron en un capítulo anterior. Nuevamente, solo un

subconjunto de las funciones disponibles es realmente requerido por los niveles de
implementación definidos. Estos se resumen a modo de referencia a continuación.

5
6.1.5 Tabla de implementación de subconjuntos

La siguiente tabla muestra los requisitos de soporte en cada nivel de implementación para todos
grupos de objetos de datos DNP3 y variaciones.

La tabla enumera todos los grupos de objetos definidos y variaciones. Cuando se requiere soporte
de un grupo de objetos particular, se muestra una 'X' en el nivel en que se requiere soporte, y los
códigos de función y calificador se enumeran a la derecha de la tabla. Tenga en cuenta que los
niveles de subconjuntos más altos incluyen automáticamente los requisitos de los niveles
inferiores.

6
7
8
9
10
11
6.2 Interoperabilidad entre dispositivos DNP3

La interoperabilidad entre dispositivos DNP3 se obtiene de todo lo siguiente. Estos son

adicionales a los documentos de especificación 'Basic Four'.

• Especificación de subconjuntos mínimos de implementación

• Un grupo de usuarios activo y un comité técnico
• Boletines técnicos dando aclaraciones según sea necesario
• Documentos de perfil del dispositivo
• Reglas de implementación
• Prueba de conformidad

6.2.1 Documento de perfil del dispositivo

El documento de perfil del dispositivo es una herramienta clave de DNP3 para proporcionar
interoperabilidad entre los dispositivos DNP3 y los sistemas. Es un documento obligatorio que
debe ser proporcionado por el fabricante para cualquier equipo que cumpla con la norma DNP3.
Aborda problemas de nivel de aplicación y nivel de enlace de datos, pero no problemas de capa
física.

El documento de perfil del dispositivo consta de estas secciones:

• Perfil del dispositivo

• Tabla de implementación
• Lista de puntos (opcional)
• El perfil del dispositivo contiene las siguientes partes:
• Identificación del dispositivo y del fabricante
• El nivel DNP3 más alto admitido
• Función del dispositivo
• Desviaciones (características adicionales) a los requisitos de definición de subconjuntos
• Detalles de configuración

La tabla de implementación tiene el formato que se muestra en la tabla de implementación de

ejemplo y enumera todos los grupos de objetos y variaciones admitidos, y la función y los códigos
calificadores de cada uno.

Se incluye un documento de perfil de dispositivo de muestra en el Apéndice.

El documento de implementación del subconjunto DNP3 proporciona el siguiente diseño que

puede usarse para la lista de puntos opcional.

6.2.2 Confirmando la interoperabilidad de los dispositivos

Para garantizar que un sistema DNP3 sea interoperable con todas sus partes componentes,
incluidos el maestro, las RTU y los IED, es necesario examinar los perfiles del dispositivo para
cada dispositivo.
12
Los perfiles del dispositivo de los dispositivos esclavos mostrarán el nivel base DNP3, así como
los objetos de datos adicionales y las funciones que se implementan. El nivel de DNP3 para
dispositivos maestros que se conectan a estos debe como mínimo soportar el mismo nivel de
DNP3, más los de las características adicionales que se pretenden utilizar.

El documento de perfil del dispositivo también enumera muchos detalles de configuración,

incluidas configuraciones predeterminadas para confirmaciones, reintentos y otros detalles. Se
debe verificar que todos estos sean compatibles con la implementación planificada.

Confirmando la interoperabilidad:

• Determinar el modo de sondeo DNP3 para ser utilizado

• Determinar el rango de dispositivos esclavos
• Ensamblar los documentos del perfil del dispositivo para el rango de dispositivos esclavos
• Determinar el nivel mínimo requerido de DNP3
• Determinar funciones por encima de este nivel que requerirán soporte
• Determinar objetos de datos por encima del nivel base seleccionado que requerirá soporte
• Examinar perfiles de dispositivos para RTU y establecer compatibilidad con IED
• Examinar los perfiles del dispositivo para la estación maestra y establecer la
compatibilidad con las RTU

6.3 Reglas de implementación y recomendaciones

Las siguientes subsecciones resumen las reglas y recomendaciones que aparecen en el documento
de definición de subconjunto DNP3 Subset Definitions, Versión 2, noviembre de 1995. Estas
reglas y recomendaciones proporcionan información que amplía y aclara lo contenido en los
documentos de Basic Four.

6.3.1 Respuestas de error

Las respuestas de error se definen para hacer frente a los efectos secundarios de tener niveles.
Estas son las posibilidades de que un dispositivo de un nivel sea sondeado para objetos de datos
que no puede proporcionar.

Tipos:

• Solicitud no válida para su nivel

• Solicitud no válida para el dispositivo en particular

Estos son reportados por las indicaciones internas bits 0-2.

Bit Descipción Caracteristica

0 Código de función no El nivel de implementación no admite esta función en objetos de
implementado datos especificados
1 1. La implementación no admite este grupo de objetos / variación
Objetos solicitados 2. Solo para objetos estáticos: el dispositivo no tiene objetos de
desconocidos este grupo / variación
No se debe usar para objetos de evento si la solicitud está definida
para este nivel

2 Parámetros no válidos Algunos o todos los objetos de este grupo / variación están fuera
del rango especificado. Los objetos dentro del rango pueden

13
 enviarse con respuesta.

Nulo Los bits 0-2 se borraron y No hay objetos disponibles principalmente utilizados en respuesta
no se devolvieron objetos a encuestas de eventos. También se puede usar para encuestas
estáticas donde no se especificó ningún rango.

Los objetos de evento también son un caso especial, porque aunque no están vinculados
a un dispositivo físico y pueden no existir en un momento determinado, es posible que no
haya nuevos eventos que informar. En este caso, el dispositivo debe proporcionar una
respuesta nula en lugar de una respuesta de 'objetos solicitados desconocidos'.

6.3.2 Clases de datos y eventos

El método más simple de referenciar datos en las solicitudes en DNP3 es llamar a objetos por
clase. De hecho, esta es una suposición fundamental detrás de los subconjuntos mínimos de
implementación, que en su nivel más bajo dependen del uso de llamadas por clase para obtener
muchos objetos. Esto se proporciona al requerir que todos los dispositivos tengan sus objetos de
datos estáticos asignados a clase 0 y todos los objetos de evento asignados a una de las otras
clases. El documento del subconjunto define una relación entre las variaciones de los objetos del
tipo de evento y clase. Las variaciones de objeto de tipo de evento se deben asignar por defecto
como clase 1, 2 o 3, pero no clase 0. La clase 0 se debe asignar por defecto a puntos de datos
estáticos solamente. Los dispositivos de nivel 3 deben permitir que un maestro habilite o
deshabilite el informe de eventos para un punto. A habilitar el informe de eventos: el maestro
asignaría el punto a la clase de datos requerida 1, 2 o 3.

Para desactivar el informe de eventos, el maestro asignaría el punto a la clase 0. Los dispositivos
de nivel 1 o 2 no necesitan admitir la activación o desactivación de informes de eventos por el
maestro. Para estos dispositivos, se requieren asignaciones predeterminadas para ser
incorporadas.

Reglas:

• Todos los objetos estáticos son por definición clase 0

• Los objetos de evento están por definición en la clase 1, 2 o 3 (pueden ser configurables)
• Todos los objetos de evento deben asignarse por defecto a la clase 1, 2 o 3
• Los dispositivos esclavos de nivel 3 deben permitir la inhabilitación de informes de
eventos

6.3.3 Variación predeterminada

Si una solicitud maestra no especifica una variación particular para un punto, entonces el esclavo
debe envía la variación por defecto. Esto puede ser configurable. Esto ocurre cuando el maestro
solicita por clase, o usa variación de objeto cero.

6.3.4 orden de las respuestas

Un esclavo debe preservar la secuencia de orden de evento cuando responde solicitudes de datos
por clase. En particular, cuando una solicitud de lectura requiere múltiples clases, los datos del
evento no deben ser devueltos en grupos de clase, pero más bien en secuencia de ocurrencia.

6.3.5 Acciones en el inicio del dispositivo esclavo

14
Las siguientes acciones deben ocurrir al inicio de un dispositivo esclavo:

• El dispositivo debe reiniciar el bit IIN.

• Si está configurado para respuestas no solicitadas, debe enviar uno al inicio
• Esta respuesta no debe contener datos ni toda la información estática
• Esta respuesta también puede contener datos de eventos no informados. Si se proporciona,
estos deben ser incluidos en el mensaje antes de los datos estáticos

Se recomienda que si un dispositivo no informa todos sus datos estáticos al inicio, el maestro debe
sondear inmediatamente todos los datos estáticos y de eventos.

6.3.6 Respuestas no solicitadas

Si se admiten respuestas no solicitadas, entonces:

• El perfil del dispositivo esclavo debe indicar que las respuestas no solicitadas son
compatibles
• Debe identificar qué objetos y funciones de datos pueden usar este modo
• El uso de respuestas no solicitadas debe poder configurarse fuera de
• El maestro debe ser capaz de desactivarlos dinámicamente usando un deshabilitar solicitud
no solicitada, código de función 21
• Un esclavo debe enviar una respuesta no solicitada al inicio, independientemente de si las
respuestas no solicitadas han sido previamente desactivadas por una estación maestra
solicitud

Los esclavos de nivel 2 o superior pueden informar objetos de datos estáticos en respuestas no
solicitadas en virtud de las siguientes condiciones:

• Al encender el dispositivo
• Cuando los bits de la bandera de estado del objeto de datos cambian

Otras reglas

• La dirección de destino principal para las respuestas no solicitadas debe ser configurable
en el dispositivo
• Todos los niveles de maestro deben soportar respuestas no solicitadas

6.3.7 Funcionamiento de salidas binarias

• Todos los esclavos deben poder analizar las operaciones en los bloques de salida del relé
de control
• Todos los esclavos deben poder analizar todos los códigos de función de salida y tipos de
control, por ejemplo, seleccionar / operar, y pulso encendido. No puede responder con una
función desconocida, pero puede responder con una operación no compatible con el estado
del relé de control bloque de salida si no es compatible con la función

Recomendaciones:

• El uso de solicitudes de escritura a salidas binarias no se recomienda porque hay no hay

comentarios del éxito de la operación
• El método recomendado es usar un bloque de salida de relé de control

15
 • Si se usa una escritura directa, entonces un comentario por separado del estado binario
debería ser usado

6.3.8 Fragmentos y marcos

• Los fragmentos de la capa de aplicación no deben superar los 2048 bytes

• Todos los dispositivos deben aceptar marcos de capa de enlace de datos de tamaño máximo
(292 bytes)
• Un maestro no debe enviar solicitudes de fragmentos múltiples
• Un maestro debe aceptar respuestas de múltiples fragmentos
• Un esclavo debe incluir todos los datos de respuesta en un solo mensaje de respuesta.

No debe responder con respuestas múltiples

Recomendaciones:

• El tamaño máximo de los fragmentos debe ser configurable en maestro y esclavo

dispositivos
• La elección de calificadores y objetos por parte de los maestros debería optimizarse para
minimizar el uso de ancho de banda.

6.3.9 Objetos múltiples

• Todos los dispositivos esclavos deben poder analizar una solicitud principal que contenga
cualquier subconjunto de todos los objetos soportados por el dispositivo

• Todos los dispositivos maestros deben poder analizar una sola respuesta de esclavo, o no
solicitados respuesta esclava, que contiene cualquier subconjunto de los objetos del dispositivo
maestro.

6.3.10 Confirmación y reintentos

• Todos los niveles de dispositivos maestros y esclavos pueden elegir si requieren o no

confirmación de los marcos de enlace de datos
• Un maestro o esclavo debe transmitir un cuadro de confirmación de enlace de datos si lo
solicita un código de función de solicitud de confirmación de envío.
• Un maestro o esclavo debe transmitir una respuesta de confirmación de capa de aplicación
si lo solicita el bit de confirmación
• Si un esclavo admite reintentos de capa de aplicación, estos deben ser configurables y estar
deshabilitados de manera predeterminada

Si un esclavo está esperando una confirmación de capa de aplicación, y recibe una nueva solicitud:

• Debe asumir que la confirmación no viene

• Conservar los datos de eventos enviados en el mensaje anterior
• Procesar la nueva solicitud.

Recomendaciones:

• La habilitación de las confirmaciones de enlace de datos debe ser configurable en

dispositivos maestros y esclavos
16
 • Un esclavo debe solicitar solo respuestas de confirmación de capa de aplicación de la
siguiente manera:
– En los datos del evento. El esclavo borra los eventos enviados al recibir la
confirmación
– En grandes mensajes salientes de varios fragmentos. Esto permite el control de flujo
por maestro
– Cuando se requiere una acción particular en respuesta a un estado esclavo, como un
vuelco, o un desbordamiento de búfer
• Un esclavo solo debería usar los reintentos de la capa de aplicación para los mensajes no
solicitados

Esto es porque:

• La capa de enlace de datos ya puede haber realizado reintentos

• Los reintentos de capa de enlace de datos solo retransmiten cuadros, no fragmentos.

Los maestros no deben solicitar confirmaciones de capa de aplicación porque son redundantes
cuando la solicitud requiere una respuesta del esclavo.

6.3.11 Banderas en objetos.

Los dispositivos esclavos pueden ignorar si un maestro solicita datos con o sin banderas, y
pueden enviar los datos solicitados con o sin una bandera a elección del esclavo.

Las reglas son:

• Esclavo puede decidir cuándo proporcionar bandera.

• Esclavo puede ignorar si el maestro pide bandera o no.
• Si el esclavo no proporciona bandera, se puede suponer que el punto es normal, es decir,
no se han establecido los bits de falla.
• Un maestro debe ser capaz de procesar variaciones de objetos con o sin banderas

6.3.12 Variaciones de 16 y 32 bits.

 Un esclavo debe tener una configuración predeterminada para las respuestas de variación
de objetos a solicitudes no específicas.
 Estas son peticiones de clase o variación 0.
 El esclavo responde con variación por defecto.
 El esclavo debe responder con una variación específica si así lo solicita.
6.3.13 Objetos analógicos sobre rango.

• Si un dispositivo de hardware está fuera de rango, se establece un indicador de

sobrerrango.
• Pero los datos de hardware se reportan inalterados
• Esto podría ser +2047 o -2048 para un DAC de 12 bits, por ejemplo

Si un dispositivo de hardware está fuera del rango:

• Se establece un bit de sobrerrango en el campo de bandera.

• Los datos se informan tal como están desde el dispositivo.

17
 Si un valor medido está dentro del rango del hardware, pero excede el que puede representarse
mediante la variación de objeto de datos solicitada, se devuelve un valor positivo o negativo
máximo.

6.3.14 Roll-over de contador

Hay un problema en la interpretación de la bandera de vuelco para los objetos de contador.

Esto se debe a la flexibilidad proporcionada por las variaciones de objeto, lo que significa que
un maestro no sabrá si un contador se transfirió a 16 bits o 32 bits.

• Los esclavos pueden elegir no configurar la bandera de transferencia.

• El punto de vuelco debe especificarse en el perfil del dispositivo.
• Un esclavo debe tener una configuración predeterminada para las respuestas de variación
de objetos a solicitudes no específicas. Esto especificará el tamaño del objeto contador
predeterminado.
• Un esclavo debe proporcionar al menos 16 bits de un contador de 32 bits si se sondeó para
el objeto contador de 16 bits.
• El maestro debe sondear con la frecuencia suficiente para evitar el vuelco en los sistemas
encuestados.

Se recomienda que las banderas de vuelco no sean configuradas por los dispositivos esclavos
y sean ignoradas por los maestros.

6.3.15 Eventos de entrada binaria con etiqueta de tiempo.

• La secuencia del evento debe ser preservada

• Solicitudes de objetos de eventos no específicos, es decir, para la devolución de datos de
clase 0 de variación:
• Objeto de evento con etiqueta de tiempo, o
• Objeto de evento sin etiqueta de tiempo, o
• Ambos. En este caso, el dispositivo debe ser configurable para limitar la notificación a
uno o el otro.

6.3.16 Operaciones de congelación.

• Un maestro debe solicitar operaciones de congelación en objetos del contador binario

(objeto 20), no en objetos mostrados congelados (objeto 21).
• Los dispositivos de nivel 2 o 3 deben admitir operaciones de congelación en objetos de
contador binarios, si los tienen.
• No están obligados a admitir lecturas de objetos mostrados congelados.

6.3.17 Sincronización de tiempo.

Un dispositivo esclavo no necesita admitir mediciones de retardo ni operaciones de escritura en

tiempo y fecha si nunca establece el bit de indicación interna requerido de sincronización de
tiempo. Se recomienda que si se utilizan objetos de evento de tiempo relativos, se debe usar un
objeto CTO no sincronizado si el maestro no ha configurado el tiempo del esclavo.

6.4 Prueba de conformidad.

18
6.4.1 General.

Una de las fortalezas reconocidas de DNP3 es la existencia de procedimientos detallados de

prueba de certificación de cumplimiento. Estos son producidos y mantenidos por el grupo de
usuarios DNP3. Actualmente, los procedimientos de prueba de certificación especifican los
requisitos y procedimientos de prueba para las pruebas de conformidad de IED con los niveles
1 y 2 de DNP3. Los documentos también contienen algunas aclaraciones y extensiones a los
documentos básicos cuatro.

Es importante tener en cuenta que los procedimientos de certificación se centran en los

requisitos mínimos, tal como se implementan en los IED en lugar de a nivel de las estaciones
maestras SCADA. Esto muestra que, aunque se puede garantizar la conformidad y la
interoperabilidad para los sistemas que cuentan con equipos certificados para el nivel 1 o el
nivel 2, no hay garantía de funciones y funciones por encima de estos niveles. Por lo tanto, si
un sistema debe incorporar una amplia gama de equipos con especificaciones extendidas (IED
con muchas funciones por encima del subconjunto de implementación de nivel 2), entonces
las pruebas de seguridad específicas pueden ser apropiadas.

6.4.2 Especificación.

La especificación del protocolo se clarifica mediante el procedimiento de certificación que se

compone de los siguientes documentos:

• Cuatro básicos.
• Capa de enlace de datos DNP versión 3.00
• DNP Version 3.00 Funciones de transporte.

• DNP versión 3.00 Capa de aplicación

• DNP versión 3.00 Capa de biblioteca de objetos de datos
• DNP versión 3.00 Definiciones de subconjuntos Versión 2.00
• Notas técnicas publicadas por el Comité Técnico
• Procedimiento de certificación de dispositivo electrónico inteligente DNP3-2000 Nivel 1
19
 • Procedimiento de certificación de dispositivo electrónico inteligente DNP3-2000 Nivel 2

Esta lista demuestra que para garantizar el cumplimiento con DNP3 es necesario tener en cuenta
todas las notas publicadas por el Comité Técnico, las definiciones de los subconjuntos los
procedimientos de certificación, así como los documentos básicos cuatro.

6.4.3 Requisitos del procedimiento de certificación

Hay tres partes principales en el procedimiento de certificación. Estos son:

• Información general que incluye una visión general, notas, definiciones y referencias
documentos.
• Revisión previa a la prueba que describe la revisión previa a la prueba de escritorio y de
escritorio
• Los procedimientos de prueba, con cada procedimiento definido:
• Sujeto de prueba
• Comportamiento deseado
• Procedimiento de prueba

La siguiente tabla muestra una descripción general del contenido de los procedimientos de
certificación. Incluyendo los títulos específicos de las materias de prueba. Los documentos del
procedimiento de certificación son separar para el nivel 1 y el nivel 2, sin embargo, las principales
diferencias se encuentran en la capa de aplicación funciones solo El documento de nivel 2
específica un número mayor de sujetos de prueba que para el documento de nivel 1.

20
21
6.4.4 Autoridades de certificación
6.4.5
El grupo de usuarios DNP3 ha autorizado tres casas de prueba para llevar a cabo pruebas de
conformidad y emitir certificados de conformidad para DNP3. Las pruebas de conformidad de
terceros no son requisito para usar DNP3, pero si un usuario final requiere la certificación, esto
solo puede ser obtenido de una de estas autoridades.
Autoridades de prueba autorizadas:
• Sistemas de control avanzado (Georgia, EE. UU.)
• Reltronics (Canadá)
• Soluciones de subredes (Calgary, Canadá)

6.5 Elección DNP3 y opciones de comunicaciones

El diseñador de un sistema SCADA que utiliza DNP3 debe seleccionar un modo operativo para
la adquisición de datos del sistema. Mientras que muchos sistemas antiguos de SCADA se basan
en la adquisición de datos puramente encuestados, DNP3 ofrece la opción de informar por
excepción operación. La ventaja que brinda este modo operativo es un ahorro sustancial en el
ancho de banda uso.
En lugar de dispositivos esclavos que informan el estado de todos sus puntos en respuesta al
maestro sondeos de estación, informan solo cambios. Este método supone, y requiere, que el
maestro SCADA puede retener de manera confiable su registro del estado actual del esclavo y
que cualquier de los cambios en ese estado se informarán de manera confiable al maestro. Cuando
la operación típica de Se considera que los sistemas SCADA es evidente que un sistema de este
tipo puede hacer ahorros en la cantidad de datos que se comunican Esta reducción en la
comunicación los requisitos pueden traducirse para permitir que se conecte un número mucho
mayor de esclavos a una ruta de comunicación dada de lo contrario podría ser el caso. De hecho,
la combinación de operación encuestada versus no encuestada e informe por excepción combinar
para hacer cuatro variaciones. La documentación de DNP3 identifica los siguientes cuatro modos
de operación y los identifica por orden decreciente de eficiencia en el uso de las comunicaciones
ancho de banda.

Un modo comúnmente utilizado es informe por excepción no solicitado. Este modo da seguridad
contra el fracaso de los sistemas de comunicaciones, al tiempo que conserva el beneficio de la
limitación
Uso de Ancho de Banda. Esto soluciona un problema que puede ocurrir con el funcionamiento en
reposo, que es fallas de comunicación no detectadas. En un sistema completamente inactivo, si
un enlace falla no hay forma de detectar el error porque el maestro puede no estar intentando
iniciar cualquier comunicación sobre ese enlace. En este caso, la falla solo sería aparente si el
maestro intentó llevar a cabo una acción de control.
Al implementar un modo de operación informe por excepción no solicitado, la frecuencia de la
encuesta de antecedentes y la cantidad de información buscada por este se puede ajustar a
proporcionar un rendimiento óptimo del sistema. Por ejemplo, una encuesta de fondo periódica
podría ser solía devolver datos muy limitados. Esto consumiría solo un pequeño ancho de banda,

22
pero probar el funcionamiento continuo del sistema de comunicaciones tan bien como una
información más grande la encuesta lo haría.
A veces, la operación estática sondeada se usará para tareas críticas particulares combinadas con
informe por excepción no solicitado para la mayoría de la adquisición de datos.
El modo de implementación mínimo admitido está definido por los documentos de definición de
subconjunto para sondear informe por excepción. Sin embargo, los documentos recomiendan que
uno de los informes por modos de excepción debe estar disponible para cualquier implementación
de DNP3.
A este efecto, se hacen las siguientes recomendaciones específicas:
• Todos los dispositivos esclavos deben informar datos de eventos
• Todos los dispositivos maestros deben admitir un modo de operación de informe por excepción

6.6 Sincronización de tiempo

6.6.1 Método general para sincronización de tiempo

Una de las características importantes de SCADA de DNP3 es que proporciona un sellado de

tiempo de eventos. El sellado de tiempo en DNP3 proporciona una resolución de eventos de un
milisegundo.
Para que los eventos coincidan correctamente en un sistema, es esencial que los relojes en todas
las estaciones externas están sincronizados con el reloj de la estación maestra.
La sincronización de un reloj de estación de salida se realiza enviando un objeto de fecha y hora
(objeto 50, variación 1) a la estación. Sin embargo, hay un retraso finito en la transmisión del
maestro a la estación, y si esto no se tiene en cuenta al configurar el reloj, sería establecer
retardado por este tiempo de transmisión. Este tiempo de retraso puede deberse a almacenamiento
y retransmisión retrasos introducidos por una variedad de dispositivos a lo largo de la ruta de
transmisión, que incluyen:

• Tiempo en búferes de módem

• Tiempo en búferes de radio de datos
• Tiempo en almacenamientos intermedios de repetidores almacenados y reenviar

Además de estos, el lector también podría agregar la posibilidad de retrasos en el procesamiento

entre el nivel de aplicación y los niveles inferiores, o 'retrasos en la acumulación' tanto en el
maestro como Estación de salida. Estos serían de hecho significativos, excepto que las cuentas de
especificación DNP3 para estos requiriendo que parte de la función de sincronización de tiempo
se realice en Capa de enlace de datos. El enlace de datos es necesario para registrar la hora de
transmisión o recepción del primer bit de cualquier mensaje de tiempo de retraso. Al transmitir el
mensaje, la capa de enlace de datos desencadena un congelamiento del reloj de la estación
maestra, que se almacena como MasterSendTime. Similar, cuando una estación esclava recibe un
mensaje de tiempo de retraso, debe almacenar una congelación del reloj local como
RtuReceiveTime.

DNP3 proporciona la medición del tiempo de retardo de ida y vuelta por el Código de función 23
Medición de retraso. El procedimiento se muestra a continuación. Procedimiento de medición de
retardo:

 El maestro envía el código de función 23 Medición de retardo

 Registros maestros inician el tiempo de transmisión como
MasterSendTime
 Estación de salida registra el tiempo de recepción como RtuReceiveTime
 La estación de salida comienza a enviar una respuesta y registra el
tiempo como RtuSendTime

23
  RtuTurnAround que es RtuSendTime - RtuReceiveTimeEstación de
salida incluye en la respuesta un objeto Time Delay (objeto 52, variación
1 o 2) que tiene el valor del tiempo de respuesta RtuTurnAround
 Master congela su reloj como MasterReceiveTime al recibir la respuesta

La estación maestra ahora calcula el retardo de propagación unidireccional tomando el promedio

de los tiempos de ida y vuelta de viaje:
Delay = (MasterSendTime – MasterReceiveTime – RtuTurnAround)/2

El tiempo de Estación de salida ahora se ajusta mediante el siguiente procedimiento:

 El maestro envía una solicitud de escritura que contiene el objeto de fecha y hora
(objeto grupo 50, variación 1). El valor de tiempo es la hora del reloj maestro al
comenzar enviando este mensaje MasterSend más el retraso calculado. Este es el
tiempo que el maestro quiere que se establezca la estación. Si la estimación de
demora es correcta, el mensaje se recibirá en la estación en tiempo real =
MasterSend + Demora.
 Estación de salida recibe el primer bit de mensaje en el momento RtuReceive.
 Estación de salida ahora establece el tiempo de Estación de salida con el siguiente
cálculo:
Adjustment = CurrentRtuTime – RtuReceive
NewRtuTime = Time in Time and Date Object + Adjustment

Tenga en cuenta que el punto para almacenar el tiempo de RtuReceive es que puede producirse
algún retraso antes de escribir realmente NewRtuTime, sin causar ningún error. Cualquier tiempo
adicional la demora se toma en cuenta al determinar el ajuste. Debe observarse que este método
asume los tiempos de viaje de ida y vuelta. Son iguales, y los tiempos de viaje de los mensajes
son repetibles. En la medida en que estas suposiciones no son verdaderas, el tiempo establecido
será un error. También es relevante señalar que se han proporcionado las funciones de
sincronización horaria DNP3 para cubrir la situación de una ruta de comunicación de ancho de
banda relativamente bajo entre maestro y el esclavo. En esta situación, los retrasos principales
están en la ruta de comunicación misma. Donde DNP3 se transporta a través de redes de área
local o amplia (LAN o WAN) usando DNP3 sobre TCP / IP o UDP / IP se aplican diferentes
consideraciones. Estos temas son discutidos en otro lugar en este texto.

6.6.2 Sincronización de tiempo global

El tiempo puede sincronizarse utilizando una solicitud global y la dirección global FFFF. Esto
puede solo se utilizará si la ruta retrasa a todas las estaciones remotas son lo suficientemente
similares como para mantener los errores dentro de límites aceptables.

6.7 DNP3 sobre TCP / IP y UDP / IP

6.7.1 Consideraciones generales

Inherente al concepto de un sistema SCADA es la presencia de sistemas de comunicación que

enlazar uno o más dispositivos maestros con generalmente un número de esclavos ubicados
remotamente dispositivos. La escala de las distancias involucradas y la naturaleza de los datos
transmitidos han dictado las tecnologías utilizadas para llevar las comunicaciones. Los sistemas
utilizados a menudo implican arrendamiento líneas, o líneas PSTN y módems analógicos (FSK),
y enlaces de radio que utilizan radios analógicos o de datos. Las velocidades de datos involucradas
están típicamente en el rango de 2400 a 9600 baudios.

24
Como DNP3 se concibió originalmente, su capa física se especificó como el uso de RS-232C
comunicaciones asíncronas bit-serial. Esto es consistente con lo históricamente típico sistema de
comunicaciones descrito anteriormente y fue una elección natural. Sin embargo, DNP3 se
desarrolló en la industria eléctrica, que se caracteriza por requisitos de comunicaciones de corto
y largo alcance. Por ejemplo, en una subestación entorno, una gran cantidad de dispositivos como
medidores, relés y otros IED pueden ser utilizado. Cuando DNP3 se utiliza en una situación de
distancia corta como esta, una configuración de múltiples usos se puede lograr mediante el uso
de RS-485. Sin embargo, esto está limitado a la operación semidúplex solo un dispositivo puede
conducir la línea a la vez, y hay un límite de 32 dispositivos en un RS-485 circuito. Sin embargo,
independientemente del mérito técnico de esta solución, hay tendencias más amplias operando
que están llevando las comunicaciones en una dirección diferente. Donde los dispositivos finales
son inteligentes, es decir, tienen procesamiento a bordo, pueden ser conectados al resto del sistema
a través de un concentrador de datos o dispositivo de control, como RTU. Es el hecho de que
estos son ahora dispositivos inteligentes que han cambiado la naturaleza de requisitos de
comunicaciones. Donde en sistemas más antiguos, el sistema SCADA se detendría en la RTU y
luego estar conectado a los dispositivos finales, esto ya no es cierto. Hoy, la necesidad para la
comunicación de los tramos de protocolo desde el dispositivo final hacia arriba. En el otro
extremo de la escala, los requisitos para las comunicaciones también se han convertido más
extenso. Donde una vez las plantas en funcionamiento individuales eran en gran parte islas, poco
conectadas con otras ubicaciones, esto ya no es cierto. Los entornos operativos de hoy han
cambiado para que las organizaciones puedan operar en áreas geográficas más grandes, y los
sistemas de comunicaciones han cambiado en paralelo con esto. Un componente principal de esto
es la adopción generalizada de redes de área local y amplia (LAN y WAN) para proporcionar
conectividad de datos entre las organizaciones. Estas tecnologías son cada vez más utilizado en
la industria de servicios eléctricos como en muchas otras industrias para los muchos beneficios
ellos traen.

Por lo tanto, coincidente con el crecimiento de los protocolos SCADA abiertos de DNP3 y
IEC60870-101 ha habido una revolución en la conectividad de toda la organización, y esto es
basado en el uso de LAN y WAN. Dentro de una subestación o planta operativa, una LAN puede
ser utilizada para proporcionar comunicaciones confiables de alta velocidad entre equipos locales,
así como a través de enrutadores a LAN cercanas o remotas, o a una WAN de nivel empresarial.
Debido a los beneficios que estas tecnologías proporcionan han llegado a ser omnipresentes, y
ahora se encuentran en salas de control, el piso de la planta y la subestación, todas las áreas donde
no hace muchos años raramente fueron encontrados. No es sorprendente entonces que haya
surgido la presión de llevar DNP3 a través de una red entorno, y esto ha resultado en la extensión
de la especificación DNP3 para incluir esto. El Comité Técnico del Grupo de Usuarios DNP3 ha
definido un método para transportar DNP3 involucrando el uso del conjunto de protocolos de
Internet para las capas de transporte y red, y la capa física de Ethernet. Los aspectos técnicos de
hacer esto se discuten en el siguiente secciones El siguiente diagrama muestra la topología de un
sistema en red que usa DNP3 y da una idea de cómo el sistema de control puede encajar en el
sistema en red general.

25
La información técnica en las siguientes subsecciones se deriva del documento DNP3
Transporte de DNP3 en redes de área local y amplia, versión 1.0, diciembre 1998. Este documento
está disponible en el sitio web del Grupo de usuarios DNP3 y debe examinarse si se requiere
información más detallada.

6.7.2 Conjunto de protocolos de Internet

El conjunto de protocolos de Internet es el grupo de programas que proporcionan los servicios del
Internet. Estos incluyen protocolo de Internet (IP), protocolo de control de transmisión (TCP),
usuario protocolo de datagrama (UDP), protocolo de transferencia de archivos (FTP) y protocolo
simple de transferencia de correo (SMTP). De estos nos preocupamos por los que proporcionan
el transporte y la red servicios, TCP, UDP e IP. La relación de estos se muestra en el siguiente
diagrama.

26
El diagrama muestra que TCP y UDP proporcionan servicios de transporte, y cada uno se
comunica con los servicios de red provistos por IP. Esto a su vez se comunica con el protocolo
de red local, que en este caso se muestra como Ethernet (IEEE 802.3). Las funciones de los tres
protocolos se discuten en las siguientes subsecciones.
Protocolo de Internet

El protocolo de Internet proporciona lo que se denomina un servicio de datagrama. Proporciona

un medio de enviar paquetes de datos individuales, llamados datagramas desde una fuente a un
destino específico. Las direcciones de origen y destino se transportan en el encabezado del
datagrama como 32 bits campos. IP no ofrece ninguna garantía de entrega ya que no hay
reconocimientos ni errores la comprobación está limitada a una suma de comprobación simple
solo del encabezado. La responsabilidad de estas funciones se deja a niveles más altos. IP también
proporciona fragmentación de datos en pequeños paquetes según lo requerido por la red sobre la
cual está pasando el datagrama, y para el re ensamblaje de los fragmentos en el datagrama original
en el extremo de destino. El servicio de protocolo de Internet también se denomina servicio sin
conexión porque no hay enlace. Pasos de establecimiento o monitoreo de un enlace están
involucrados. Cada datagrama es una independiente comunicación única.

Los datagramas de protocolo de Internet tienen un encabezado de 20-24 bytes seguido de sus
datos. Ellos puede ser, en teoría, de hasta 65 K bytes, pero tiene un tamaño máximo recomendado
de
576 bytes.

Protocolo de Control de Transmisión

El protocolo de control de transmisión (TCP) proporciona un medio fiable y orientado a la

conexión de transmitir datos de un usuario a otro. Está diseñado para hacer uso de IP para
transmitir datagramas para proporcionar una transmisión libre de errores sobre las capas
subyacentes al destino Capa de TCP
TCP establece enlaces de comunicación entre 'sockets' en cada extremo. Siguiendo inicialización
del enlace, las comunicaciones pueden tener lugar en ambas direcciones entre cada fin. TCP
divide los datos en segmentos y los pasa a IP, lo que a su vez puede fragmentarlos en datagramas
más pequeños.
TCP tiene un encabezado de segmento de 20-24 bytes. El tamaño del segmento está determinado
por el más bajo 'Tamaño máximo de segmento' configurado en cada extremo del enlace, o en 536
bytes para un sistema no local Dirección IP.

Protocolo de datagramas de usuario

El protocolo de datagrama de usuario (UDP) está destinado a proporcionar un medio para acceder
al datagrama servicio de IP más o menos directamente desde la capa de transporte. Un datagrama
UDP se traduce a un datagrama de IP enviado, con la información adicional de origen y destino
puertos, más una suma de comprobación. UDP no proporciona la característica de entrega
confiable de TCP, para Por ejemplo, si se detecta un error, el paquete simplemente se descartará.
Porque UDP es basado en paquetes solamente, no está orientado a la conexión como lo es TCP.
Esto le permite utilizar el difunde el modo de direccionamiento IP para enviar a múltiples destinos
simultáneamente.

6.7.3 Transporte de DNP3 a través de una red

La idea de llevar DNP3 a través de un entorno de red implica la encapsulación de los datos marcos
de la capa de enlace de datos DNP3 dentro de los marcos de la capa de transporte del protocolo

27
de Internet suite y permitir que la pila de protocolo entregue los marcos de capa de enlace de datos
DNP3 a la ubicación de destino en lugar de la capa física DNP3 original.
El siguiente método ha sido recomendado por el Comité Técnico:

• DNP3 utilizará el conjunto de protocolos de Internet para transportar mensajes de

LAN / WAN
• El enlace físico recomendado es Ethernet (otros pueden usarse sin embargo)
• Todos los dispositivos deben soportar TCP y UDP
• TCP debe usarse para WAN
• Se recomienda encarecidamente TCP para LAN
• UDP puede usarse para LAN de segmento único altamente confiables
• UDP es necesario si se requieren mensajes de difusión
• La pila del protocolo DNP3 debe conservarse por completo
• Las confirmaciones de la capa de enlace deben estar deshabilitadas
La pila de protocolos resultante se muestra en el siguiente diagrama.

En referencia al diagrama de la pila de protocolos, es evidente que el pseudo-transporte y las

capas de enlace de datos del protocolo DNP3 permanecen en la pila y actúan por encima y
capas de transporte, red y enlace de datos proporcionados por TCP, IP y el protocolo Ethernet
LAN. El lector podría preguntar si las capas inferiores del protocolo DNP3 podrían tener sido
eliminado Sin embargo, hay elementos esenciales del protocolo DNP3 en las capas DNP3
inferiores y estos son necesarios para funcionar juntos. Estos incluyen direccionamiento y
detección de errores, que se encuentran en el cuadro de enlace de datos. Para obtener los
beneficios de la integración perfecta con TCP / IP no es posible intentar para modificar esos
protocolos para permitir las características requeridas por DNP3. En cambio, el TCP / IP los
protocolos se usan como estándar para proporcionar el transporte de los mensajes DNP3 a
través de red.

6.7.4 Otros problemas

Confirmaciones de capa de enlace

28
Las confirmaciones de capa de enlace son innecesarias cuando se usa DNP3 sobre TCP / IP y son
específicamente No permitido. TCP proporciona un mecanismo de entrega confiable y está
respaldado en el capa de aplicación por confirmaciones cuando sea necesario.
Sincronización de tiempo

El uso de la medición de retardo de sincronización de tiempo FC 23 no es apropiado para su uso

durante redes porque todos:

 El retraso de propagación a lo largo de la red es inconmensurablemente pequeño (típico

para LAN) o
• Las colisiones en la red provocan un retraso variable (también en LAN)
• El retraso de propagación es impredecible debido al cruce de enrutadores
• La pila de protocolos causa un retraso variable

Debido a estas limitaciones, el Comité Técnico ha definido un procedimiento para permitiendo la

sincronización del tiempo a través de una LAN local solamente. La sincronización no está
definida en todo por una WAN. El procedimiento requiere que el maestro use un datagrama UDP
para transmitir registre la función de tiempo actual (FC 24) a todos los esclavos que lo requieran.
El controlador de ethernet es se requiere tener la capacidad de registrar el tiempo de transmisión
y recepción del último byte del mensaje. Estos tiempos deben ser los mismos debido al pequeño
retraso de propagación del LAN. Luego, el maestro envía una hora y una fecha al último objeto
de tiempo registrado (grupo de objetos 50, variación 3) que permite a los esclavos determinar un
ajuste de tiempo. Tanto el registro la función de tiempo actual y el último objeto de tiempo
registrado se han definido recientemente en DNP3 para este propósito.

29
 7
Vista previa de IEC 60870-5

7
7.1 ¿Qué es IEC 60870-5?
IEC 60870-5 se refiere a una colección de estándares producidos por la Internacional Comisión
Electrotécnica, o IEC, para proporcionar un estándar abierto para la transmisión de Control e
información de telemetría SCADA. El estándar proporciona una descripción funcional detallada
para el equipo de telecontrol y sistemas para controlar procesos geográficamente generalizados,
en otras palabras, para SCADA sistemas. El estándar está diseñado para su aplicación en las
industrias eléctricas, y tiene datos objetos que están destinados específicamente para tales
aplicaciones, sin embargo, no se limita a aplicaciones tales como objetos de datos que son
aplicables a aplicaciones SCADA generales en cualquier industria Sin embargo, el protocolo IEC
60870-5 se usa principalmente en industrias de países europeos. Cuando el conjunto de normas
IEC 60870-5 se completó inicialmente en 1995 con la publicación del perfil IEC 870-5-101,
cubrió solo la transmisión en un ancho de banda relativamente bajo circuitos de comunicación
bit-serial. Con el uso cada vez más extendido de la red tecnología de comunicaciones, IEC 60870-
5 ahora también proporciona comunicaciones por redes que usan el conjunto de protocolos TCP
/ IP. Esta misma secuencia de desarrollo ocurrió para DNP3.

En esta vista previa, las principales características de IEC 60870-5 se describen bajo los títulos
listados a continuación. Todas estas áreas se examinan con mayor detalle en los siguientes
capítulos de Fundamentos y consideraciones avanzadas de IEC 60870-5, en las cuales el protocolo
será descrito en detalle al centrarse en la especificación del protocolo desde el nivel físico hasta
el nivel de aplicación del usuario.
• Estándares
• Topología del sistema
• Estructura de mensaje
• Direccionamiento
• Transporte de mensajes
• Funciones de aplicación y nivel de usuario
• Objetos de datos de aplicación
• Interoperabilidad

7.2 Estándares

IEC 60870 se refiere a un estándar producido en varias partes entre 1988 y 2000 por la Comisión
Electrotécnica Internacional o IEC. IEC es una organización hecha de comités nacionales de todo
el mundo, y su función es promover cooperación en materia de normalización en los campos
eléctrico y electrónico. Esta norma originalmente se hizo referencia como IEC 870, pero
posteriormente se agregó el prefijo '60'. El estándar IEC 60870 está estructurado de manera
jerárquica, que comprende seis partes más una serie de estándares acompañantes. Cada parte se
compone de una serie de secciones, cada uno de los cuales ha sido publicado por separado de
manera progresiva. Además de partes principales, hay cuatro estándares 'complementarios' que
proporcionan los detalles finos del estándar para un campo particular de aplicación. Los
estándares complementarios amplían la definición proporcionados por las partes principales de la
norma mediante la adición de objetos de información específicos para el campo de aplicación. La
estructura del estándar IEC 60870 se ilustra en la Figura 7.1, siguiendo. Esto muestra las partes

30
principales del estándar, más las secciones y el compañero normas relacionadas con los protocolos
de transmisión.
Cerca de la parte inferior de la figura, se puede ver el estándar complementario IEC 60870-5-101.
Se titula 'Compañero standard para tareas básicas de telecontrol'. De hecho, es este documento
eso se entiende con mayor frecuencia cuando se discute IEC 870 o IEC 60870 en el contexto de
Sistemas SCADA. Esto es porque fue solo con el lanzamiento de este documento que un completo
definición para un protocolo de transmisión SCADA completo fue creado, ya que es este
documento que proporciona todos los objetos de datos de nivel de aplicación que son necesarios
para SCADA operación. Sin embargo, aunque IEC 60870-5-101 completa la definición para el
protocolo de transmisión, incluye muchas referencias a los detalles contenidos en las Secciones 1
a 5 de la Parte 5.

El cuarto estándar complementario, IEC 60870-5-104 también es de particular importancia en la

comprensión de la norma tal como se utiliza hoy en día, porque define el transporte de Mensajes
de aplicación IEC 60870-5 a través de redes. Su título completo es 'Acceso a la red usando
Standard Transport Profiles 'que se refiere a su uso de TCP / IP para el transporte y protocolos de
red. Este estándar complementario se publicó en diciembre de 2000, unos seis años después de
que se publicó IEC 60870-5-101. Por supuesto, proporciona una muy diferente el mecanismo
físico y de transporte de datos según IEC 60870-101, pero deja la mayor parte de funciones de
nivel de aplicación y objetos de datos inalterados. Los estándares se discuten en mayor detalle en
la siguiente sección de este curso. Los puntos clave a tener en cuenta en esta vista previa son la
estructura jerárquica del estándar, el hecho de que se ha desarrollado y emitido progresivamente,
y el hecho de que los dos Los principales documentos descriptivos son los perfiles IEC 60870-5-
101 y más recientemente IEC 60870-5-104.

7.3 Topología del sistema

IEC 60870-5-101, o T101, admite enlaces de comunicación punto a punto y multidrop portando
comunicaciones de datos de poco ancho de banda bit-serial. Proporciona la opción de usar
comunicación equilibrada o desequilibrada a nivel de enlace. Con comunicación desequilibrada,
solo el maestro puede iniciar comunicaciones transmitiendo cuadros primarios. Esta simplifica el
diseño del sistema porque no hay necesidad de apoyar la prevención de colisiones.
31
Todas las comunicaciones se inician mediante solicitudes de estación maestra, como para solicitar
datos de usuario si disponible.
La comunicación equilibrada está disponible, pero esto está limitado solo a los enlaces punto a
punto.
Por lo tanto, aunque T101 puede admitir mensajes no solicitados de un esclavo, no puede hacerlo
durante un topología multipunto y debe emplear un esquema de sondeo cíclico para interrogar a
estaciones
Comunicación equilibrada: limitada solo a enlaces punto a punto:

• Cualquiera puede iniciar una transacción

• Mejor eficiencia del uso del sistema de comunicaciones
• Problemas de colisión ya que dos estaciones pueden transmitir simultáneamente. Colisión
se requiere evitar y recuperar
• Sin embargo, solo para enlaces punto a punto bajo T101
• Comunicación desequilibrada: adecuada para multidrop:
• Solo el maestro puede enviar cuadros primarios
• No se requiere evitar colisiones
• La función de capa de enlace de datos del esclavo es más simple

Bajo IEC 60870-5 hay una estructura jerárquica asumida, por lo que para cualquier dos estaciones
que se comunican entre sí, una es la estación de control, y la otra es la estación controlada.
También hay una 'dirección del monitor' definida y una 'dirección de control'. Por lo tanto, los
datos supervisados, como los valores analógicos del campo, se envían en el monitoreo dirección,
y los comandos se envían en la dirección de control. Si una estación envía ambos monitoreados
datos y envía comandos, actúa como una estación controlada y una estación de control. Esto se
define como operación de modo dual. Es acomodado por el protocolo, pero requiere ese uso está
hecho de direcciones de originador en la ASDU.

7.4 Estructura del mensaje

La estructura de mensaje bajo IEC 60870-5-101 está formada por un marco de capa de enlace de
datos llevando la dirección del enlace y la información de control, una bandera para indicar si los
datos de la Clase 1 están disponibles, y datos de aplicación opcionales. Cada cuadro puede llevar
un máximo de un servicio de aplicación unidad de datos, o ASDU. La Figura 7.2 muestra la
estructura del marco de enlace de datos y la estructura de la capa de aplicación ASDU llevada por
él.

32
En el caso donde no se requieren datos de usuario en el marco, ya sea un marco de longitud fija,
o un se puede usar acuse de recibo único. Estos proporcionan un uso eficiente de ancho de banda
de comunicaciones.

7.5 Direccionamiento

Bajo el direccionamiento IEC 60870-5-101 se encuentra tanto en el enlace como a nivel de la

aplicación. Los el campo de dirección de enlace puede ser 1 o 2 octetos para desequilibrado, y 0,
1 o 2 octetos para equilibrado comunicaciones. Como las comunicaciones equilibradas son punto
a punto, la dirección de enlace es redundante, pero puede incluirse por seguridad. La dirección de
enlace FF o FFFF se define como una dirección de difusión, y puede usarse para dirigirse a todas
las estaciones en el nivel de enlace.
En el nivel de aplicación, la ASDU contiene una dirección común de 1 o 2 octetos. Esto es definida
como la dirección de la estación de control en la "dirección de control" y la dirección de la estación
controlada en la "dirección de monitoreo". La dirección común de la ASDU combinado con la
33
dirección del objeto de información contenida dentro de los datos se combina para hacer la
dirección única para cada elemento de datos.
Al igual que en DNP, puede haber más de una dirección lógica o común por dispositivo. Como
para el nivel de enlace, la dirección FF o FFFF se define como una dirección de difusión. Por lo
tanto para enviar un mensaje de difusión es necesario incluir esta dirección tanto en el enlace de
datos como campos de dirección de aplicación.
Opcionalmente por sistema, las direcciones del originador también se pueden llevar dentro del
ASDU. Esto no se muestra en la Figura 7.2, pero es una parte opcional de la causa de la
transmisión campo.
La dirección del objeto de información es de 1 a 3 octetos de longitud, y puede proporcionarse
solo una vez dentro de una ASDU, o para cada objeto de información separado dentro de una
ASDU. Esta permite la transmisión eficiente de bloques de información secuencial.

7.6 Versión en red

Según IEC 60870-5 hay dos métodos diferentes para transportar mensajes. Estos son en efecto
dos protocolos diferentes, pero estrechamente relacionados. El primero es IEC 60870-5-101, o
T101, que proporciona comunicaciones en serie de bits en comunicaciones de ancho de banda
bajo canales Este método utiliza el marco de enlace de datos que se muestra en la Figura 7.2 junto
con el definido procedimientos para transportar los datos a través de la red de comunicaciones. El
segundo método se definió mucho más recientemente con el lanzamiento de IEC 60870- 5-104,
o perfil T104. En este protocolo, los niveles más bajos del protocolo han sido completamente
reemplazado por los protocolos de red y transporte TCP e IP. Estos protocolos proporcionar el
transporte de las unidades de datos del servicio de aplicación (ASDU) que se muestran en la
Figura 7.2 a través de redes corporativas de área local y redes de área amplia usando estos
protocolos estándar. La estructura del protocolo o "pila de protocolos" se muestra en la Tabla 7.1

Considerando que T101 proporciona una definición completa de la pila de protocolos hasta el
físico nivel, esto no se proporciona en T104 como capa física y de enlace existente y variada las
operaciones son empleadas.
En general, aparte de la operación completamente diferente del transporte de mensajes, la
operación del protocolo en la aplicación y el nivel de usuario no se alteran. Algunos específicos
las excepciones están en el área de sincronización de tiempo y en mensajes de difusión.

7.7 Objetos de datos de aplicación

IEC 60870-5 tiene información sobre un conjunto de objetos de información que son adecuados
para ambos Aplicaciones SCADA, y aplicaciones de sistemas eléctricos en particular. Cada
diferente tipo de datos tiene un número de identificación de tipo único. Solo se incluye un tipo de
datos en cualquier ASDU, y como se ilustra en la Figura 7.2, la identificación del tipo es el primer
campo en la ASDU. Los tipos de objetos de información se agrupan por dirección y por tipo de
información, como sigue:

34
7.8 Interoperabilidad
La interoperabilidad según IEC 60870-5 se logra mediante una declaración de interoperabilidad
de diez páginas. Esto identifica todos los diferentes modos de operación, opciones configurables,
ASDU, causas de transmisión, y otra información que es importante para garantizar la
compatibilidad. Porque IEC 60870-5 tiene una estructura simple en términos de sus tipos de datos
y datos abordar las opciones, este enfoque es relativamente sencillo. Es necesario verificar
compatibilidad de implementaciones de estaciones de control con implementaciones de
estaciones controladas y asegúrese de que todos los tipos de datos requeridos sean compatibles.

35