INSTITULO POLITÉCNICO NACIONAL

INSTITULO POLITÉCNICO NACIONAL

CENTRO DE INVESTIGACIÓN Y DESARROLLO

DE TECNOLOGÍA DIGITAL

“DATALOGGER PARA SUBESTACIONES ELÉCTRICAS”

TESINA

QUE PARA OBTENER LA

ESPECIALIDAD EN SISTEMAS INMERSOS

PRESENTA:

ELIZABETH MENDOZA ROBLES

BAJO LA DIRECCIÓN DE:

M.C. DAVID JAIME SAUCEDO MARTÍNEZ

JUNIO 2015 TIJUANA, B.C., MÉXICO

1

ÍNDICE

1 Introducción …………………………………………………. 7

1.1 Objetivo ………………………………………….. 8

2 Sistemas SCADA ………………………………………… 9

2.1 Unidad Terminal Remota …..……………………….. 10

2.2 Unidad Terminal Maestra …………………………… 11

2.3 Protocolos de Comunicación …………………….. 12

3 Protocolo DNP3 ………………………………….…….... 14

3.1 Características del Protocolo DNP3 …………… 15

3.2 Modelo EPA …………………………… 15

3.3 Formato de la Trama DNP …………………………... 16

3.4 Capa de Enlace de Datos …………………………… 18

3.4.1 CRC ………………………………….…..….. 20

3.4.2 Funciones de Transporte ……………….…… 21

3.4.2.1 Encabezado de Transporte …………….. 22

3.4.3 Capa de Aplicación …………………………… 23

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

3.4.5 Encabezado del Objeto ………………………… 29

2

3.5 Biblioteca de Objetos …………………………………………….. 30

4 Protocolo MODBUS ………………………………………….. 36

4.1 Formato de Trama …………………………………………… 37

4.2 Modos de Transmisión Serial …………………………..... 38

4.2.1 Modo UTR ………………………………………………….. 39

4.2.2 Modo ASCII …………………………………………………. 39

1.1 Códigos de Función …………………………………………...... 40

1.2 Tipos de Datos ………………………………………………....... 42

1.3 CRC ………………………………………………………….......... 43

5 Pruebas Realizadas …………………………………………… 44

5.1 Conclusiones ……………………………………………………….. 48

3

ÍNDICE DE FIGURAS

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

ÍNDICE DE TABLAS

Tabla 1: Códigos de Funciones.

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

CAPÍTULO 1

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

propo

inform

intero

BJETIVO

Realizar u

ner el diseñ

mación.

El prototip

perable y ca

un estudio d

ño de un sis

po de simu

apaz de trab

de los proto

stema de ad

ulador será

ajar con dist

8

ocolos utiliza

dquisición, a

á de fácil i

tintas marca

F

ados en las

almacenami

implementac

as de IED’s.

Figura 1: Esq

s subestacio

iento y adm

ción y uso,

squema de co

ones eléctric

ministración

, será flexib

comunicación

cas y

de la

ble e

ón.

9

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.

Localización rápida de errores.

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

e inter

cual s

a 2: Sistema

RTU La Unidad

das digitales

toma la fu

mente las s

uptor, medic

ad para el mo

LA RTU se

rfaces como

se puede mo

HM

a SCADA

d Terminal R

s, analógicas

nción como

señalizacion

ciones de lín

onitoreo y co

e comunica

o Consolas d

onitorear y co

I

Remota es

s o controles

o concentra

es, obtiene

neas de tran

ontrol de una

con una est

de Control L

ontrolar una

IE

10

un dispositiv

s, aunque ex

ador de info

de manera

smisión o

a subestació

tación centra

ocal igualme

subestación

RTU

ED’s

vo al cual s

xisten algun

ormación ya

a serial o p

cualquier o

ón eléctrica.

al conocida

ente conocid

n eléctrica.

U

se le conect

nas modalida

a que en v

por Ethernet

otro dato qu

como MTU,

das como H

tan directam

ades en don

vez de con

t los estado

ue pudiera s

con otras R

MI a través

mente

nde la

nectar

os de

er de

RTU’s

de la

11

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

Capa 7

Capa 6

Capa 5

Capa 4

Capa 3

Capa 2

Capa 1

Aplicación

Presentación

Sesión

Transporte

Red

Enlace de Datos

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

CAPÍTULO 3

PROTOCOLO DNP

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

3.1 CARACTERÍSTICAS DEL PROTOCOLO DNP3

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

Transferencia de archivos

Direccionamiento sobre 65000 dispositivos

Sincronización de tiempos

Estampas de Tiempos

Confirmación de enlace de datos

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.

3.2 MODELO EPA Enhanced Performance Architecture

Arquitectura de comunicación

Figura 3: Capas de comunicación

Aplicación

Pseudo‐Transporte

Data Link

Física

16

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.

17

3.3 DESCRIPCION GENERAL DE UNA TRAMA DNP

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

C

O

N

T

R

O

L

T

H

A

C

F

C

C

R

C

OBJ.

HEADER

I

N

I

C

I

O

D

N

P

D

E

S

T

S

O

U

R

C

E

C

R

C

18

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.

Figura 4 Formato de Trama DNP

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.

CONTROL: 1 BYTE

Figura 5: Byte de Control

<<Block 1>> <‐Block n‐>

START START USER USER

0X05 0X64 DATA DATA

<‐ Fixed Length Header (10 Octets) ‐> <‐ Body ‐>

CRC CRC…

FORMATO DE LA TRAMA

LENGTH CONTROL DESTINATION

<< Block 0 >>

SOURCE CRC

MSB LSB

FCB FCV Primary

0 DFC Secondary

7 6 5 4 3 2 1 0

BYTE DE CONTROL

DIR PRM FUNCTION CODE

19

DIR: Dirección de la transmisión física

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

Códigos de Función

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

0011110101100101= Se elimina el más significativo

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

23

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)

Accept Response Send Response


Important change detected

Accept Response Send Unsolicited Response


Maestro Esclavo (IED,RTU)

REQUEST OBJECT … OBJECT

HEADER HEADER HEADER

Application Request Format

DATA DATA

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

RESPONSE OBJECT … OBJECT

HEADER HEADER HEADER

Application Response Format

DATA DATA

Aplication Control Function Code

AC FC

Request Header

25

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

Response Header

7 6 5 4 3 2 1 0

FIR FIN CON SEQUENCE

26

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

0 Confirm Solicita la confirmación

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

Direct Operate

‐No Acknowedgement

selecciona salida y la opera pero no

respuesta de la solicitud

7 Inmediate Freeze

8

Inmediate Freeze

‐No Ack

9 Freeze and Clear

10

Freeze and Clear

‐No Ack

11 Freeze with time

12

Freeze with time

‐No Ack

13 Cold Restart

14 Warm Restart

15 Initialize Data to Defaults

16 Initialize Application

17 Start Application

18 Stop Application

Control Function Codes

Freeze Function Codes

Transfer Function Codes

Transfer Function Codes

Application Control 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.

En Solicitudes:

0: no válido cuando el quailifier es 11

1: tamaño del identificador = 1 Byte



4: reservado

5: reservado

6: reservado

7: reservado

OBJECT QUALIFIER RANGE

OBJECT HEADER

30

En respuestas:

0: no valido cuando el quilifier es 11




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 Delta Counter(Objeto 20 , Var 3)

16 Bit Delta Counter(Objeto 20 , Var 4)

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 Object (Objetos de 50 al 59)

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 Object(Objetos de 90 al 99)

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.

Figura16: Capas involucradas en una comunicación serial

Layer ISO/OSI Model

7 Aplicación Protocolo de Aplicación MODBUS

6 Presentación ‐‐‐

5 Sesión ‐‐‐

4 Transporte ‐‐‐

3 Red

2 Enlace de Datos Protocolo MODBUS Serial

1 Física EIA/TIA ‐232 o 485

37

Ciclo de Pregunta-Respuesta

Figura 17: Protocolo MODBUS Ciclo Pregunta-Respuesta

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

38

Figura 18: Trama MODBUS

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

CodeData Error Check

<‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐PDU‐‐‐‐‐‐‐‐‐‐‐‐‐>

<‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ADU‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐>

39

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;

Bits por Byte: 1 bit de arranque.

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

Figura 19: Trama del mensaje modo ASCII

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 AddressFunction

CodeData LRC End

Función Descripción

1 Read Coil Status

2 Read Input Status

3 Read Holding Registers

4 Read Input Registers

5 Force Single Coil

6 Preset Single Register

7 Read Exception Status

8 Diagnostics

9 Program 484

10 Poll 484

11 Fetch Comm Event Ctr

12 Fetch Comm Event Log

13 Programm Controller

14 Poll Controller

15 Force Multiple Coils

16 Preset Multiple Registers

17 Report Slave ID

18 Program 884/M84

19 Reset Comm Link

20 Read General Reference

21 Write General Reference

41

Códigos de Excepción

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

1 Illegal Function

2 Illegal Data Address

3 Illegal Data Value

4 Server Device Failure

5 Acknowledge

6 Server Device Busy

8 Memory Parity Error

0A Gateway Path Unavailable

0B

Gateway Target Device

Failed to Respond

Solicitud Inicial

Funtion

Code

Data

Request

Funtion

Code

Data

Response

Recibe la respuesta

Cliente Server

Ejecuta la acción

Inicia la respuesta

42

Figura 21: Transacción MODBUS con errores (Respuesta por Excepció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

Funtion

Code

Data

Request

Exception

Funtion

Code

Data

Response

Recibe la respuesta

Cliente Server

Error Detectado en

la solicitud

Dato Tipo de Objeto Ejecución

Discretes Input Single bit Read‐Only

Coils Single bit Read‐Write

Input Registers 16 bit word Read‐Only

Holding Registers 16 bit word Read‐Write

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:

Addr Func Data

Count Data Data Data Data

CRCLo

CRCHi

Figura 23: Byte CRC

CAP

PRU

SOFT

Reset

enlace

Figura

PÍTULO

UEBAS Y

TWARE UTI

t Link: Mens

e de comuni

a 23: Mensaj

5

RESULTA

LIZADO: SI

aje enviado

icación

je entre un I

ADOS

MULADOR

a la RTU pa

IED-MTU “R

44

ASE 2000

ara verificar

Reset Link”

r que se ha eestablecido correctamennte el

Barrid

Figura

Figura

do por Objeto

a 24: Trama

a 25: Traduc

o 1, Var.0. (E

en formato

cción del me

Entradas Dig

hexadecima

ensaje entre

45

gitales)

al –Señales

un IED y la

Digitales

a MTU – Señ

ñales Digitalees

Barrid

Figura

Figura

do por Objeto

a 26 : Trama

a 27: Traduc

o 30, Var.0.

a en formato

cción del me

(Entradas A

o hexadecima

ensaje entre

46

Analógicas)

al –Señales

un IED y la

Analógicas

a MTU – Seññales Digitalees

47

Pruebas para obtención de bytes de CRC

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

[1] Adrew S. Tanenbaum

Computer Networks

Third Edition, 1996 by Prentice Hall PTR

[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

[4] Malcom Smith / Jim McFadyen

Sep1991 Ver.0.00

DNP v3.00 Data Link Layer Protocol Description

http://www.dnp.org

[5] MODICON

PI-MBUS-300 Rev J, Jun 1996

Modbus Protocol

http://www.modbus.org

[6] Steve Mackay, Edwin Wright, Deon Reynders, John Park

Practical Insdustrial Data Nerworks

Desing, Installation and Troubleshooting

Documents

INSTITULO POLITÉCNICO NACIONAL