Download pdf - INSTITULO POLITÉCNICO NACIONAL

Microsoft Word - ELIZABETH_v5DE TECNOLOGÍA DIGITAL
1
ÍNDICE
3 Protocolo DNP3 ………………………………….…….... 14
3.2 Modelo EPA …………………………… 15
3.4.1 CRC ………………………………….…..….. 20
3.4.3.1 Formato de Solicitudes y Respuestas….. 23
3.4.3.2 Encabezado de Aplicación Request-Response …………………………………………………. 24
3.4.3.3 Control de Aplicación ……………….…… 25
3.4.3.4 Control de Flujo …………………….…… 26
3.4.3.5 Código de Función ………………………. 27
3.4.4 Indicaciones Internas …………………………… 28
2
4 Protocolo MODBUS ………………………………………….. 36
4.2 Modos de Transmisión Serial …………………………..... 38
4.2.1 Modo UTR ………………………………………………….. 39
4.2.2 Modo ASCII …………………………………………………. 39
1.3 CRC ………………………………………………………….......... 43
Figura 1: Esquema de comunicación.
Figura 2: Ejemplo de una Trama DNP. Figura 3: Capas de comunicación. Figura 4: Formato de Trama DNP. Figura 5: Byte de Control. Figura 6: Transport Header Figura 7: Request Header. Figura 8: Response Header. Figura 9: Secuencia de un mensaje DNP. Figura 10: Application Request Format. Figura 11: Application Response Format. Figura 12: Request Header. Figura 13: Response Header. Figura 14: Aplication Control Field. Figura 15: Object Header. Figura 16: Capas involucradas en una comunicación serial. Figura 17: Protocolo MODBUS Ciclo Pregunta-Respuesta. Figura 18: Trama MODBUS. Figura 19: Trama del mensaje modo ASCII. Figura 20: Transacción MODBUS sin errores. Figura 21: Transacción MODBUS con errores (Respuesta por Excepción). Figura 22: Byte CRC. Figura 23: Mensaje entre un IED-MTU “Reset Link”. Figura 24: Trama en formato hexadecimal - Señales Digitales. Figura 25: Traducción del mensaje entre un IED y la MTU -Señales Digitales. Figura 26: Trama en formato hexadecimal - Señales Analógicas. Figura 27: Traducción del mensaje entre un IED y la MTU -Señales Analógicas. Figura 28: CRC’s de una trama DNP.
4
Tabla 2: Códigos de Funciones para Solicitudes.
Tabla 3: Códigos de Funciones de MODBUS.
Tabla 4: Códigos de Excepciones – MODBUS.
Tabla 5: Tipos de Datos - MODBUS.
5
ÍNDICE DE ACRÓNIMOS
AC: Application Control. ADU: Application Data Unit AI: Analog Input COS: Change of State CRC: Cyclic Redundancy Check DNP: Distributed Network Protocol. DI: Digital Input DO: Digital Output DCF: Data Flow Control DIR: Dirección de la transmisión EPA: Enhanced Performance Architecture. FCB: Frame Control Bit. FCV: Frame Count Valid. HDLC: High Level Data Link Control HMI: Human Machine Interface IED: Intelligent Electronic Device IEC: International Electrotechnical Comission IEEE: Institute of Electrical and Electronics Engineers. IETF: Internet Engineering Task Force IIN: Internal Indication ISO: International Organization for Standardization I/O: Input/Output. IP: Internet Protocol. LEN: Length MTU: Master Terminal Unit MAC: Media Access Control MB: Modbus Protocol MBAP: Modbus Application Protocol OSI: Open Systems Interconnections.
6
PRM: Primary Message PDU: Protocol Data Unit PLC: Programmable Logic Controller RTU: Remote Terminal Unit. RS-232: EIA/TIA Standard RS-485: EIA/TIA Standard SCADA: Supervisory Control and Data Acquisition SEQ: Sequence Number SOE: Sequence of Events TCP: Transmission Control Protocol UDP: User Datagram Protocol
7
INTRODUCCIÓN
En el siguiente documento se describen dos de los protocolos más utilizados en las
subestaciones eléctricas y unidades generadoras de energía eléctrica. El propósito de
estudio de los protocolos DNP y MODBUS es lograr proponer un sistema que sirva de
“Simulador de Protocolo” el cual sea capaz de enviar solicitudes utilizando los distintos
objetos y variaciones definidas en el protocolo, así como también interpretar las respuestas
enviadas de los Dispositivos Electrónicos Inteligentes(IED’s).
Posteriormente se anexan imágenes de pruebas realizadas en campo con algunos
equipos en donde se podrá ver el intercambio de mensajes de manera “traducida”.
Se realizó el estudio del protocolo DNP y MODBUS para conocer e interpretar los
mensajes enviados entre una MTU y RTU, con el objetivo de crear un prototipo para
simular una MTU y poder interrogar a los distintos IED’s instalados en una subestación
eléctrica, a través del protocolo DNP, utilizando como medio físico de comunicación el
puerto serial RS-232, los dispositivos serán configurados utilizando la aplicación del
fabricante del IED que corresponda, pero serán capaces de probarse con el simulador para
la obtención y comprobación de datos.
1.1 OB
CAPÍTULO 2
SISTEMAS SCADA
Los Sistemas de Supervisión, Control y Adquisición de Datos (SCADA) permiten la
adquisición, gestión y control local o remoto del sistema (eléctrico en nuestro caso) mediante
una interfaz gráfica “HMI” la cual permite la comunicación del usuario con el sistema.
Un sistema SCADA es un software de monitoreo capaz de servir de intermediario
entre los distintos dispositivos de control instalados. Existen distintas ventajas al utilizar un
sistema SCADA. A continuación de mencionarán algunas de ellas:
Conexión de cualquier tipo de sensores, transductores, multimedidores, etc. de
cualquier fabricante.
Almacenamiento de grandes cantidades de información.
Utilización de un sistema de control remoto (RTU) en comunicación directa con una
HMI.
Los datos pueden ser desplegados según lo requiera el usuario.
Uso de tecnologías celulares para mantener informado al personal encargado de
anomalías presentadas mediante el envío de alarmas.
Una vez instalado las necesidades de mantenimiento son mínimas.
Figura
2.1
entrad
RTU
físicam
interru
utilida
2.2 MTU
La Estacion Maestra es el equipo principal o “Servidor” el cual es responsable de la
comunicación con las RTU’s, obtiene la información de todas las subestaciones que
necesitan ser monitoreadas y controladas de manera remota por un Centro de Control. La
MTU tiene las siguientes funciones:
Establecer la comunicación con cada RTU.
Hacer la interrogación (“polling”) para la obtención de datos de cada RTU,
almacenamiento de alarmas y eventos.
Diagnóstico de fallas de comunicación con RTU’s.
Interfaz de comunicación RS-232
Para la comunicación se utiliza el estándar RS-232, un estándar de interfaz se
conoce como las características o detalles mecánicos y eléctricos que permitirán que
equipos de diferentes manufacturas se comuniquen entre sí de manera eficiente. La
conexión física para DNP es orientada a conexión asíncrona, soporta 8 bits de datos, 1 bit
de arranque, 1 bit de paro, sin paridad. La capa física debe proveer Envió, Recepción,
Conexión, Desconexión y Estado.
Características Eléctricas:
Es estándar R-232 está diseñado para la conexión de dos dispositivos conocidos
como:
DTE: Data Terminal Equipment. Utiliza las terminales 2 y 3 para transmitir y recibir
respectivamente.
12
DCE: Data Communitations Equipment. Utiliza las terminales 3 y 2 para transmitir y recibir
respectivamente
2.3 PROTOCOLOS DE COMUNICACIÓN
Las reglas y convenciones usadas para establecer la comunicación entre dos o más
dispositivos son conocidas como “protocolo”. Básicamente un protocolo es un acuerdo entre
las partes que se están comunicando de cómo se llevara a cabo la comunicación. El
intercambio de información puede realizarse utilizando cualquier medio físico.
Los protocolos permiten que las unidades RTU/SCADA se comuniquen uno con el
otro. Las arquitecturas de red están basadas en las siete capas del modelo OSI de ISO:
Figura 3: Modelo ISO de OSI
Fisica
13
Se utiliza el modelo OSI como base para para establecer el marco de trabajo que
permitirá el intercambio de señales, mensajes y direcciones en un sistema. Existen varios
protocolos de comunicación propietarios y no propietarios, a continuación se listan algunos:
Modbus SEL DNP3 Conitel 2020
14
DNP conocido como Distributed Network Protocol fue desarrollado alrededor de 1990
por GE-Harris (anteriormente Westronic). Es un protocolo para comunicación entre equipos
inteligentes (IED’s), surge con la necesidad de crear un estándar que permitiera la
interoperabilidad entre los componentes de un sistema SCADA. Una de las características
del protocolo DNP es que es un protocolo abierto lo cual permite que sea adoptado por
distintas marcas.
La Unidad Terminal Remota es interrogada por una maestra. En las “solicitudes”
enviadas por la MTU se especifica el código de función en donde se indica el objetivo del
mensaje. El esclavo responde según la función correspondiente.
Existe una amplia variedad de tipo de objetos y variaciones en el protocolo DNP, se
consideraron sólo lo siguientes tipos de datos para delimitar el desarrollo del prototipo.
Digitales: Clase 1, (Objeto: 1, Variación: 1)
Analógicas: Clase 2 (Objeto: 30; Variación: 2)
15
Este protocolo fue desarrollado para alcanzar la interoperabilidad entre los distintos
elementos de subestaciones, como RTU’s, IED’s y MTU’s. Está basado en el estándar IEC
(Internacional Electrotechnical Commission). A continuación se mencionan las
características principales de este protocolo.
Flexibilidad
Serial asíncrono , y puede ser utilizado sobre Ethernet (TCP/UDP)
El protocolo es utilizado en sistemas eléctricos en donde se requieren estampas de
tiempo en los eventos que ocurran así como la posibilidad de que un esclavo transmita
información sin ser solicitada.
Arquitectura de comunicación
Aplicación
Capa física
Se encarga de la transmisión a través del canal de comunicación, proporciona las
características eléctricas, mecánicas, así como procedimientos funcionales para mantener el
enlace físico entre los dispositivos de una red de datos. Actualmente solo un mínimo
porcentaje utiliza la interfaz RS-232(asíncrono).
Capa de Transmisión de Datos
Se encarga del manejo de la conexión lógica entre emisor-receptor. DNP utiliza 16
bits conocidos como CRC para el manejo de errores. El tamaño máximo del frame es de 256
bytes.
Capa de Pseudo-Transporte
Esta capa divide los mensajes de la capa de aplicación en múltiples frames de
transmisión de datos. En cada frame inserta un código que ayudara a identificar el número
de mensaje que corresponda (número de secuencia), mismo que ayuda a identificar si hay
pérdida de paquetes (frames).
Capa de Aplicación
Define las funciones para la manipulación de datos y permite a los usuarios entender
la información. En esta capa se define la cantidad de bits o bytes para transmitir una señal.
Cuando los datos son demasiado grandes para un solo mensaje de la capa de aplicación, el
mensaje se fragmenta, por lo tanto un mensaje puede contener desde un solo fragmento a
múltiples fragmentos.
Ejemplo de una solicitud MaestroEsclavo
Figura 2: Ejemplo de una Trama DNP
05 64(2 Bytes): Indican el inicio de una trama DNP 0B: Longitud de la trama =11, sin contar los CRC C4: Byte de Control: Mensaje originado por la maestra, el mensaje va de Maestro a
Esclavo 00 00: Destino 0 (MSB: 00, LSB: 00) 81 00: Origen: 129 (MSB: 00, LSB: 81) 05 F7: CRC, Código para la detección de errores. C0: Transport Header. Inicio y fin de la trama con secuencia 0. C0 01: AH formado por AC y FC. AC: Inicio y fin de segmento, FC: Función 01
(Read) 01 00 06: Object Header. 01: Objeto 00: Variación 06: Qualifier (Todas las entradas
digitales) 5B 7B: CRC, Código para la detección de errores.
1 2 3 4 5 6 7 8 9 10 11
05 64 0B C4 00 00 81 00 05 F7 C0 C0 01 01 00 06 5B 7B
L
E
N
G
H
T
3.4 LA CAPA DE ENLACE DE DATOS
Encargada de proveer la transferencia de información del LSDU(Link Service Data
Unit), a través del medio físico, antes de ser enviado por el medio físico debe ser convertido
en una trama LPDU. La capa de enlace de datos es responsable de la conexión y
desconexión del medio físico sin relacionarse con la capa superior
FORMATO DE TRAMA DNP
En esta sección se describe el formato LPDU, una trama está formada por un
encabezado, seguido de bloques de datos y al final de cada bloque se agregan 16 bits de
CRC.
START: 05 64: Indican inicio de la trama DNP
LENGTH: Longitud de la trama sin contar los CRC. El valor mínimo es de 5 y el máximo de
255.
<<Block 1>> <Block n>
START START USER USER
0X05 0X64 DATA DATA
CRC CRC…
BYTE DE CONTROL
1: Estación A B 0: Estacion BA
PRM: Primary Message; Quien origina el mensaje
1: Frame from Primary(Request) 0: Frame from Secondary(Response) FCB: Frame Count Bit; Usado para eliminar pérdidas o duplicación de tramas a la misma
estación secundaria. Al inicio de la comunicación o después de una falla la estación primaria
debe reiniciar el “data link” de cada estación secundaria con la que se va a comunicar.
FCV: Frame Count Valid
1: Frame Count Bit is valid (verifica que sea correcta la transmisión de mensajes a nivel enlace de datos. 0: Ignore Frame Count Bit DFC: Data Flow Control, 1=no buffers left; Usado para prevenir el desbordamiento de buffers en una estación secundaria.
20
Tabla 1: Códigos de Función
DESTINATION: 2 Bytes, (LSB-MSB). Especifica la dirección de la estación a quien va
dirigida la trama. El primer byte corresponde al byte menos significativo.
SOURCE: 2 Bytes, (LSB-MSB). Especifica la dirección de la estación de donde es originada
la trama.
3.4.1 CRC
Los bloques de datos de usuario (User Data) pueden constar de 1 hasta 16 Bytes, a
cada bloque se le agrega un CRC para la detección de errores.
El CRC es generado utilizando la siguiente ecuación polinomial y después se invierte
antes de ser colocado en el bloque de transmisión (para el cálculo del CRC se incluyen los
bytes de START, LENGHT, CONTROL, DESTINATION y SOURCE)
X16+ X13+ X12+ X11+ X10+ X8+ X6+ X5+ X2+1
10011110101100101 = CRC Polinomio Binario
21
0X3D65 =CRC Polinomio Hexadecimal
Al invertir 1010011010111100 = 0XA6BC, se obtiene el valor con el que se
ejecutarán las operaciones XOR con el valor al cual se le quiere calcular el CRC. El proceso
realiza hasta completar 8 corrimientos de bits a la izquierda. En la figura 28 se encuentran
algunos códigos de CRC obtenidos de una trama DNP.
3.4.2 FUNCIONES DE TRANSPORTE
Las funciones de transporte se utilizan para el intercambio de mensajes entre
estaciones primarias y secundarias, (primaria: quien origina el mensaje, secundaria: quien
recibe el mensaje). La capa de pseudo-transporte toma un bloque de usuario (visto en la
parte de formato de la trama) y lo divide en varios segmentos para ser transportados por el
medio físico, lo cual da como resultado múltiples user data (TPDU’s).
Estas funciones agregan al encabezado de la capa de transporte información
necesaria para reconstruir el mensaje completo. El encabezado de la capa de transporte
contiene información para identificar si se trata de la primera trama así como su número de
secuencia
La capa de pseudo-transporte tome un TSDU (User data) y lo divide en varias
TPDU’s, cada uno es enviado a la capa de enlace de datos como LSDU (Link Service Data
Unit) para su transmisión, ocurre lo mismo de manera inversa. LSDUs son fragmentos del
tamaño mínimo en la trama FT3. Se agrega un encabezado en la capa de transporte del
tamaño de un byte esto al inicio del fragmento.
22
3.4.2.1 TRANSPORT HEADER (8bits)
Cuando una aplicación solicita la transmisión de un mensaje grande, el mensaje es
divido en fragmentos. El tamaño máximo de un fragmento es de 249 bytes. El TH se agrega
a cada fragmento, el número máximo de bytes en la trama es de 250.
Figura 6: Transport Header (Encabezado de Transporte)
Composición de función de transporte
Bit 7: FIN
0: Mas tramas 1: Fin de la trama Bit 6: FIR
0: No es la primera trama de la secuencia 1: Primer trama de la secuencia Bit 5 al Bit 0: SEQUENCE Para llevar la secuencia de la trama
7 6 5 4 3 2 1 0
TRANSPORT HEADER (8BITS)
FIN FIR SEQUENCE
3.4.2 CAPA DE APLICACIÓN
En esta sección se define el formato de los mensajes a intercambiar en las estaciones primaria y secundaria, solo la estación maestra puede enviar solicitudes a un IED, de la misma manera solo el esclavo puede enviar las respuestas. El esclavo solo atiende una petición a la vez de la maestra, y la maestra puede aceptar los mensajes no solicitados enviados por el esclavo.
Figura 9: Secuencia de un mensaje DNP
3.4.3.1 FORMATO DE SOLICITUDES Y RESPUESTAS El formato del APDU(Application Request Message Format) está formado por un bloque APCI el cual contiene información de control, normalmente es conocido como Request Header, además del APCI lo conforma un ASDU el cual lleva información que será procesada para la remota. Cada ASDU consiste de uno o más DUI(Data Unit Identifier)
Figura 10: Application Request Format
Send Request Accept Request and process
Confirmation (Optional)
Confirmation (Optional)
24
Request Header: Ayuda a identificar el propósito del mensaje Object Header Data: Identifica el tipo de objetos siguientes Data: Objetos de datos especificados en el encabezado del objeto
Figura 11: Application Response Format Request Header: Ayuda a identificar el propósito del mensaje Object Header Data: Identifica el tipo de objetos siguientes Data: Objetos de datos especificados en el encabezado del objeto
3.4.3.2 ENCABEZADOS DE APLICACIÓN (REQUEST-RESPONSE)
El encabezado de solicitud está formado por dos campos con un tamaño de un byte cada uno, en el encabezado de respuesta se adiciona un campo más conocido como “Indicaciones Internas”.
Figura 12: Request Header
Figura 13: Response Header
3.4.3.3 CONTROL DE APLICACIÓN
Es un campo que proporciona la información necesaria para construir mensajes multi-fragmentos, su tamaño es de 1 byte. Cada fragmento tiene un encabezado de aplicación y su respectivo encabezado de objeto de tal manera que cada fragmento pueda ser procesado como un mensaje individual. APLICATION CONTROL FIELD
Figura 14: Aplication Control Field FIR: Con un 1 se indica que el fragmento del mensaje es el primer fragmento de una mensaje completo de la aplicación. FIN: Con un 1 indica que el fragmento del mensaje en el fragmento final de un mensaje completo de aplicación. CON: Con un 1 indica que se espera confirmación de aplicación de la recepción del fragmento. SEQUENCE: Indica el número de fragmento
Aplication Control Function Code Internal Indications
AC FC IIN
FIR FIN CON SEQUENCE
3.4.3.4 CONTROL DE FLUJO FC: Flow Control
El flujo de solicitudes y respuestas entre la maestra y esclavos es controlado por los campos en los encabezados de respuesta y solicitud, así como también los timers de aplicación y parámetros, los cuales son los siguientes: 1) CON: Este bit habilita/deshabilita la confirmación. 2) FIR y FIN: Indican inicio o fin de la secuencia. 3) SEQUENCE: Usado para ensamblar mensajes multi-fragmentos e identificar cual respuesta corresponde a las solicitudes correspondientes. 4) Estación Maestra y Esclavo Time-outs de respuesta: Especifica el tiempo de espera por una respuesta o por una confirmación, antes de re-transmitir o abortar una transacción. La aplicación puede o no soportar la re-transmisión de transacciones en la capa de aplicación. 5) Estación Maestra y Esclavo Reintentos: La aplicación puede o no soportar reintentos a nivel aplicación. El contador de reintentos especifica cuantas veces se repetirá la solicitud si no se obtiene una respuesta, o que tan seguido se re-transmitirá una respuesta si no se obtiene confirmación de recibido.
27
3.4.3.5 FUNCTION CODE Es un código que identifica el propósito del mensaje, el tamaño de este campo es de un byte. Hay dos grupos de función (uno para solicitudes y otro para las respuestas).
Tabla 2: Códigos de Función -Solicitudes
Code Function
1 Read Lectura de objetos específicos
2 Write Almacena un dato específico en el slv
3 Select selecciona una salida
4 Operate opera una salida previamente seleccionada
5 Direct Operate selecciona una salida y la opera
6
respuesta de la solicitud
16 Initialize Application
17 Start Application
18 Stop Application
Control Function Codes
Freeze Function Codes
Transfer Function Codes
Transfer Function Codes
28
3.4.4 INTERNAL INDICATIONS Se encuentran representadas por dos campos cada una de dos bytes. Se utilizan cuando el esclavo no puede procesar la solicitud o si el dato solicitado no está disponible. Primer Byte (Con un 1 lógico se indica la activación del Bit) Bit 0: Usado para indicar que se recibió un mensaje tipo Broadcast por una estación Bit 1: Datos de Clase 1 Disponible Bit 2: Datos de Clase 2 Disponible Bit 3: Datos de Clase 3 Disponible Bit 4: Se requiere sincronización de parte de la MTU Bit 5: Utilizado para indicar que alguna salida digital se encuentra en “Local” Bit 6: Problema en el dispositivo Bit 7: Reinicio del dispositivo Segundo Byte Bit 0: Código de función no implementado Bit 1: Objetos solicitados no conocidos o no disponibles Bit 2: Rango de datos no valido Bit 3: Desbordamiento de Buffer Bit 4: Solicitud en ejecución (Solicitud duplicada) Bit 5: Configuración de la estación incorrecta o corrompida Bit 6: Reservado Bit 7: Reservado
29
3.4.5 OBJECT HEADER El encabezado de un objeto especifica los objetos de datos contenidos en el mensaje a ser usados para responder. El formato del encabezado del objeto es idéntico para las solicitudes y respuestas, pero la interpretación del encabezado depende de si es solicitud o respuesta y que código de función acompaña el encabezado.
Figura 15 Object Header Object (2 Bytes): Especifica el grupo de objeto y variación dentro del grupo. En este campo
solo se identifica el tipo de objeto o clase. Los objetos pueden ser asignados a 4 tipos de
clase (0-3), de tal manera que cuando se hace referencia a los objetos de una misma clase.
El primer byte se utiliza para indicar el tipo de dato(analógica, digital) y el segundo byte para
la variación (16 ó 32 bits por ejemplo en caso de analógicos). La estructura de objetos se
encuentra detallada en la parte de biblioteca de objetos.
Qualifier (1 Byte): Especifica la forma en que será interpretado el rango de datos a entregar–
solicitar.
1: tamaño del identificador = 1 Byte
4: reservado
5: reservado
6: reservado
7: reservado
4: reservado
5: reservado
6: reservado
7: reservado
Rango (1Byte): Indica la cantidad de objetos (inicio y final) . Para códigos del 0 al 5 se
tienen dos subcampos con los que se especifica las direcciones de inicio y fin. Código 6
traerá todos los datos.
3.5 BIBLIOTECA DE OBJETOS
Datos Estáticos y Eventos:
Un dato digital estático se refiere a la representación del estado de un bit (0 ó 1).
Una entrada analógica contiene el valor instantáneo transmitido.
Los eventos están asociados con algún cambio de estado, o alguna variación de
datos (“deadband” en el caso de analógicas).
Variaciones para datos analógicos estaticos
1. A 32-bit integer value with flag 2. A 16-bit integer value with flag 3. A 32-bit integer value 4. A 16-bit integer value
31
5. A 32-bit floating point value with flag 6. A 64-bit floating point value with flag
Variaciones para datos analógicos estaticos
1. A 32-bit integer value with flag 2. A 16-bit integer value with flag 3. A 32-bit integer value with flag and event time 4. A 16-bit integer value with flag and event time 5. A 32-bit floating point value with flag 6. A 64-bit floating point value with flag 7. A 32-bit floating point value with flag and event time 8. A 64-bit floating point value with flag and event time Binary Input Objects (Objetos del 1 al 9)
Single Bit Binary Input (Objeto 1 , Var 1)
Binary Input With Status (Objeto 1 , Var 2)
Binary Input Change Without Time (Objeto 2 , Var 1)
Binary Input Change With Time(Objeto 2 , Var 2)
Binary Input Change With Relative Time(Objeto 2 , Var 3)
Binary Output Objects (Objetos del 10 al 19)
Binary Output(Objeto 10 , Var 1)
Binary Output Status (Objeto 10 , Var 2)
Control Relay Output Block (Objeto 12 , Var 1)
Pattern Control Block (Objeto 12 , Var 2)
Pattern Mask(Objeto 12 , Var 3)
Counter Objects (Objetos del 20 al 29)
32 Bit Binary Counter (Objeto 20 , Var 1)
16 Bit Binary Counter (Objeto 20 , Var 2)
32
32 Bit Counter Without Flag(Objeto 20 , Var 5)
16 Bit Counter Without Flag(Objeto 20 , Var 6)
32 Bit Delta Counter Without Flag(Objeto 20 , Var 7)
16 Bit Delta Counter Without Flag(Objeto 20 , Var 8)
32 Bit Frozen Counter(Objeto 21 , Var 1)
16 Bit Frozen Counter(Objeto 21 , Var 2)
32 Bit Frozen Delta Counter(Objeto 21 , Var 3)
16 Bit Frozen Delta Counter(Objeto 21 , Var 4)
32 Bit Frozen Counter With Time of Freeze(Objeto 21 , Var 5)
16 Bit Frozen Counter With Time of Freeze(Objeto 21 , Var 6)
32 Bit Frozen Counter Without Flag(Objeto 21 , Var 9)
16 Bit Frozen Counter Without Flag(Objeto 21 , Var 0)
32 Bit Counter Change Event Without Time(Objeto 22 , Var 1)
32 Bit Delta Counter Change Event Without Time(Objeto 22 , Var 3)
16 Bit Delta Counter Change Event Without Time(Objeto 22 , Var 4)
32 Bit Counter Change Event With Time(Objeto 22 , Var 5)
16 Bit Counter Change Event With Time(Objeto 22 , Var 6)
32 Bit Delta Counter Change Event With Time(Objeto 22 , Var 7)
16 Bit Delta Counter Change Event With Time(Objeto 22 , Var 8)
16 Bit Frozen Counter Event Without Time(Objeto 23 , Var 2)
32 Bit Frozen Delta Counter Event Without Time(Objeto 23 , Var 3)
16 Bit Frozen Delta Counter Event Without Time(Objeto 23 , Var 4)
32 Bit Frozen Counter Event With Time(Objeto 23 , Var 5)
16 Bit Frozen Counter Event With Time(Objeto 23 , Var 6)
32 Bit Frozen Delta Counter Event With Time(Objeto 23 , Var 7)
33
16 Bit Frozen Delta Counter Event With Time(Objeto 23 , Var 8)
Analog Input Objects(Objetos de 30 al 39)
32 Bit Analog Input(Objeto 30 , Var 1)
16 Bit Analog Input(Objeto 30 , Var 2)
32 Bit Analog Input Without Flag(Objeto 30 , Var 3)
16 Bit Analog Input Without Flag(Objeto 30 , Var 4)
32 Bit Frozen Analog Input(Objeto 31 , Var 1)
16 Bit Frozen Analog Input(Objeto 31 , Var 2)
32 Bit Frozen Analog Input With Time of Freeze(Objeto 31 , Var 3)
16 Bit Frozen Analog Input With Time of Freeze(Objeto 31 , Var 4)
32 Bit Frozen Analog Input Without Flag(Objeto 31 , Var 5)
16 Bit Frozen Analog Input Without Flag(Objeto 31 , Var 6)
32 Bit Analog Change Event Without Time(Objeto 32 , Var 1)
16 Bit Analog Change Event Without Time(Objeto 32 , Var 2)
32 Bit Analog Change Event With Time(Objeto 32 , Var 3)
16 Bit Analog Change Event With Time(Objeto 32 , Var 4)
32 Bit Frozen Analog Event Without Time(Objeto 33 , Var 1)
16 Bit Frozen Analog Event Without Time(Objeto 33 , Var 2)
32 Bit Frozen Analog Event With Time(Objeto 33 , Var 3)
16 Bit Frozen Analog Event With Time(Objeto 33 , Var 4)
Analog Output Object(Objetos de 40 al 49)
32 Bit Analog Output Status(Objeto 40 , Var 1)
16 Bit Analog Output Status(Objeto 40 , Var 2)
32 Bit Analog Output Block(Objeto 41 , Var 1)
16 Bit Analog Output Block(Objeto 41 , Var 2)
34
Time and Date(Objeto 50 , Var 1)
Time and Date With Interval(Objeto 50 , Var 2)
Time and Date Cto(Objeto 51 , Var 1)
Un-Synchronized Time and Date Cto(Objeto 51 , Var 2)
Time Delay Coarse(Objeto 52 , Var 1)
Time Delay Fine(Objeto 52 , Var 2)
Class Object (Objetos de 60 al 69)
Class 0 Data(Objeto 60 , Var 1)
File Object(Objetos de 70 al 79)
File Identifier(Objeto 70 , Var 1)
Device Object(Objetos de 80 al 89)
Internal Indications(Objeto 80 , Var 1)
Storage Object(Objeto 81 , Var 1)
Device Profile(Objeto 82 , Var 1)
Private Registration Object(Objeto 83 , Var 1)
Private Registration Object Descriptor(Objeto 80 , Var 2)
35
Application Identifier(Objeto 90 , Var 1)
Alternate Numeric Object(Objetos de 100 al 109)
Short Floating Point(Objeto 100 , Var 1)
Long Flaoting Point(Objeto 100 , Var 2)
Extended Flaoting Point(Objeto 100 , Var 3)
Small-Packed Binary Coded Decimal(Objeto 101 , Var 1)
Medium-Packed Binary Coded Decimal(Objeto 101 , Var 2)
Large-Packed Binary Coded Decimal(Objeto 101 , Var 3)
Objetos del 110 al 254 son reservados para futura expansión
36
CAPÍTULO 4
PROTOCOLO MODBUS
MODBUS es un protocolo flexible y de fácil implementación, fue desarrollado en
1979 por MODICON. Es un protocolo normalmente utilizado para establecer la
comunicación entre los sistemas de control supervisorio dentro de las unidades de
generación eléctrica.
Su interfaz física puede ser de tipo RS-232, RS-485, o Ethernet. Se encuentra
posicionado en la capa número 2 del modelo OSI y su funcionamiento es del tipo Maestro-
Esclavo. El protocolo define el formato para solicitudes dentro de la cual se especifica la
dirección del dispositivo, un código de función, dato enviado y el CRC. La respuesta está
constituida por la información y el campo del CRC, en caso de ocurrir un error o si el esclavo
no puede procesar la petición se genera un mensaje de error y es enviado como una
respuesta.
Layer ISO/OSI Model
6 Presentación
5 Sesión
4 Transporte
3 Red
1 Física EIA/TIA 232 o 485
37
4.1 FORMATO DE TRAMA
MODBUS define un PDU independiente de la capa de comunicación subyacente.
La unidad de aplicación de datos (ADU) es construida por el cliente que inicia la transacción,
la función indica al server qué tipo de acción ejecutara. El protocolo de aplicación MODBUS
establece el formato de la solicitud iniciada por un cliente. El tamaño del código de función
es de un byte, los códigos validos se encuentran en el rango de 1 a 255. (128 -255 se
encuentran reservados). Posteriormente se indican los códigos de función mayormente
utilizados para la adquisición de datos. El campo de datos enviado de un cliente al servidor
contiene información adicional usada para complementar la función definida por el código de
función (por ejemplo direcciones de registros o la cantidad de puntos).Si el campo de datos
es de longitud cero el Server no requerirá información adicional para ejecutar el código de
función.
El tamaño máximo del ADU es de 256bytes de los cuales 1 byte corresponden a la
dirección del Server y dos bytes al CRC, dejándole al PDU 253 bytes.
Query Message from Master
Device Address Device Address
Function Code Function Code
Eight Bit Eight Bit
Data Bytes Data Bytes
Error Check Error Check
Response Message from Slave
4.2 MODOS DE TRANSMISIÓN SERIAL
En el modo de transmisión serial el rol de “Cliente” es adoptado por la Maestro y el
Esclavo actúa como “Server”. La comunicación solo puede ser iniciada por la Maestra de la
misma manera que el protocolo DNP el Esclavo solo responde si recibe una petición por la
MTU.
Existen dos modos de solicitudes:
Modo “Unicast”: En este modo la transacción está formada por dos mensajes: Una
solicitud de parte de la Maestra, y la respuesta del Esclavo. Cada esclavo tiene una
dirección única que va de 1 a 247.
Modo “Broadcast”: La Maestra puede enviar solicitudes a todos los esclavos. Todos
los dispositivos deben aceptar la función de recibir mensajes tipo broadcast. La dirección 0
se encuentra reservada para ser utilizado en este tipo de transmisiones.
La Maestra no tiene una dirección en específico solo los esclavos deben tener
asignada una dirección única en un bus modbus.
Existen dos modos de transmisión serial ASCII o RTU. En estos modos se define la
forma de empaquetado de los mensajes y su decodificación.
Additional
Address
Function
4.2.1 MODO UTR (Unidad Terminal Remota)
La ventaja principal de este modo es que permite una mayor cantidad de datos a ser
transmitidos. Cada mensaje es transmitido en una trama de manera continua
Formato en modo UTR (11 bits):
Sistema de Codificación: 8-bit;
8 bits de datos.
1 bit de paridad (par/impar).
1 bit de paro si se utiliza paridad; 2 bits sin paridad.
Es requerido el tipo de paridad par, sin embargo puede usar paridad impar o sin
paridad. Para asegurar una mayor compatibilidad con otros productos para este caso serán
necesarios 2 bits de paro.
4.2.2 MODO ASCII
En este modo cada 8 bits de mensaje son enviados de la forma de dos caracteres
ASCII. Este modo es menos eficiente que el RTU ya que cada byte necesita dos caracteres.
El tamaño máximo de la trama MODBUS ASCII es de 513 caracteres.
Formato Modo ASCII (10 bits)
Sistema de Codificación: Hexadecimal, caracteres ASCII 0-9, A-F.
Bits por Byte: 1 bit de arranque.
7 bits de datos.
1 bit de paridad (par/impar).
1 bit de paro si se utiliza paridad; 2 bits sin paridad.
40
4.3 CÓDIGOS DE FUNCIÓN
En el código de función se especifica la acción que realizará el esclavo. Por ejemplo
el código de función 03 se traduce como una solicitud de lectura de registros.
Tabla 3: Códigos de Función MODBUS
Start Address Function
13 Programm Controller
14 Poll Controller
Tabla 4: Códigos de Excepción
Si el esclavo responde de manera normal, el código de función es idéntico al código
de función de la solicitud recibida. En caso de presentarse algún error se entrega un código
distinto para indicar error en la respuesta, también entrega información que describe el error,
a esto se le conoce como Respuesta por Excepción.
Figura 20: Transacción MODBUS sin errores
Función Descripción
4.4 TIPO DE DATOS EN MODBUS
El protocolo permite seleccione individuales de alguno de los 65536 datos y las
operaciones de escritura o lectura de los mismos.
Tabla 5: Tipos de Datos
Solicitud Inicial
Discretes Input Single bit ReadOnly
Coils Single bit ReadWrite
Input Registers 16 bit word ReadOnly
Holding Registers 16 bit word ReadWrite
43
4.5 CRC
El CRC es un campo basado en la comprobación cíclica de errores y verifica el
contenido completo del mensaje. El campo está formado por 2 bytes, y se agrega al último
de cada mensaje primero el byte menos significativo dejando al último el más significativo.
Procedimiento para el cálculo del CRC:
1. Poner en 1’s los 16bits FFFF, se conocerá como registro CRC
2. Ejecutar un OR exclusivo a los primeros 8 bits del mensaje con el byte de menor
orden de los 16bits del registro del CRC
3. Rotar a la derecha un bit del CRC (LSB)
4. Si el LSB=0 , volver al paso 3 , si LSB=1, hacer un or exclusivo con el valor A001H
5. Repetir los pasos 3 y 4 hasta haber realizado los 8 desplazamientos.
6. Repetir los pasos del 2 al 5 para los siguientes 8 bits
7. El resultado final es el valor del CRC
8. Colocar en el mensaje el valor del CRC de la siguiente manera LSB:MSB, quedando
como la siguiente imagen:
CRC Lo
CRC Hi
Barrid
Figura
Figura
Figura 28: CRC’s de una trama DNP
05 64 14 C4 00 00 81 00 26 CB
C0 C0 01 01 01 17 01 0A 1E 02 01 00 00 40 01 9D BA
CRC
CRC
48
CONCLUSIONES Y RECOMENDACIONES
El prototipo fue desarrollado en base a las necesidades de realizar pruebas de
comunicación entre IED’s y MTU’s, estas pruebas son necesarias para verificar que el
equipo fue configurado de manera correcta.
Se utiliza un dispositivo maestro (simulador-pc) para solicitar datos (señalización y/o
mediciones) o ejecutar controles a los IED’s. Los IED’s serán llamados esclavos, los cuales
solo responden si la maestra hace una petición de información, en caso contrario
permanecen inactivos.
Fueron estudiados y analizados los tipos de objeto y variación manejados por el
protocolo DNP y MODBUS esto con la finalidad de poder proporcionar un prototipo que
cumpla con los requerimientos necesarios para establecer una correcta comunicación entre
los dispositivos maestro y esclavo.
49
REFERENCIAS
[2] Gordon Clarke, Deon Reynders
Practical Modern SCADA Protocols
DNP3, IEC 60870.5 and Related Systems
[3] Hector Ruiz Veraza, David Saucedo Martínez, Enrique Estrada Bautista y Carlos García
Mendoza
Sistema De Control Supervisorio Para La Subestación Eléctrica “ACERO”, ACTA
MEXICANA DE CIENCIA Y TECNOLOGÍA, julio-septiembre de 1986, vol. IV No. 15, Instituto
Politécnico Nacional
Sep1991 Ver.0.00
http://www.dnp.org
Modbus Protocol
Practical Insdustrial Data Nerworks
Desing, Installation and Troubleshooting
Conclusiones y recomendaciones