IMPLEMENTACION DE UNA RED MODBUS/TCP

ANDRES FELIPE RUIZ OLAYA

UNIVERSIDAD DEL VALLE FACULTAD DE INGENIERA ESCUELA DE INGENIERA ELCTRICA Y ELECTRNICA PROGRAMA DE INGENIERA ELECTRNICA SANTIAGO DE CALI 2002

IMPLEMENTACION DE UNA RED MODBUS/TCP

ANDRES FELIPE RUIZ OLAYA

Trabajo de grado para optar por el ttulo de INGENIERO ELECTRNICO

Directores Ing. ASFUR BARANDICA LOPEZ Ing. FABIO GERMAN GUERRERO, M. Sc.

UNIVERSIDAD DEL VALLE FACULTAD DE INGENIERA ESCUELA DE INGENIERA ELCTRICA Y ELECTRNICA PROGRAMA DE INGENIERA ELECTRNICA SANTIAGO DE CALI 2002

RESUMEN

En este proyecto se desarrolla e implementa una red de instrumentacin y control industrial con conectividad TCP/IP (como por ejemplo Internet), capaz de ser supervisada y controlada remotamente a travs del protocolo Modbus/TCP usando el sistema embebido TINI de Dallas Semiconductor. Adems se desarrolla una interfaz de usuario grfica para acceso desde Internet va Web .

Nota de Aprobacin

El

trabajo

de

grado

titulado

IMPLEMENTACIN

DE

UNA

RED

MODBUS/TCP, presentado por el estudiante ANDRES FELIPE RUIZ OLAYA, para optar al ttulo de Ingeniero Electrnico fue revisado por el jurado y calificado como:

Aprobado.

Ing. ASFUR BARANDICA LOPEZ Director

Ing. FABIO GERMAN GUERRERO Director

Ing. EDINSON FRANCO Jurado

Ing. CARLOS RAFAEL PINEDO Jurado

AGRADECIMIENTOS

El autor expresa sus agradecimientos a:

Los directores de tesis: Ing. Asfur Barandica e Ing. Fabio German Guerrero por su grandsima colaboracin en esta etapa final de la carrera y porque de ellos aprend mucho.

A todas aquellas personas que me acompaaron a lo largo de la carrera y en la culminacin de este trabajo de grado.

A mis compaeros, profesores y en general a la comunidad universitaria de Univalle por la experiencia vivida en esta institucin.

CONTENIDO
Pag.

0. INTRODUCCIN 1. EL PROTOCOLO MODBUS/TCP

1.1 DESCRIPCIN 1.1.1 Orientado a conexin 1.1.2 Codificacin de datos 1.1.3 Interpretacin del modelo de datos 1.1.4 Filosofa de longitud implicada 1.2 VENTAJAS DEL PROTOCOLO MODBUS/TCP 1.3 ESTRUCTURA DEL PROTOCOLO 1.4 ESQUEMA DE ENCAPSULACION 1.5 CONFORMACION DE CLASES 1.5.1 Comandos Clase 0 1.5.2 Comandos Clase 1 1.5.3 Comandos Clase 2 1.5.4 Comandos especficos de la mquina/red/vendedor 1.6 DESEMPEO REQUERIDO Y ESPERADO 1.7 GUIA DE IMPLEMENTACION DEL CLIENTE Y SERVIDOR 1.7.1 Diseo del Cliente 1.7.2 Diseo del Servidor

1 8 8 9 11 11 12 13 14 17 17 18 18 19 20 21 22 22 24

2. DESCRIPCION DEL HARDWARE 2.1 LA TARJETA TINI 2.1.1 Descripcin 2.1.2 Caractersticas 2.1.3 Aplicaciones 2.1.4 Hardware de la TINI 2.1.5 Mapa de memoria del sistema 2.1.6 Sistema I/O integrado 2.1.7 Software de la TINI 2.1.8 Sistema operativo de la TINI 2.1.9 El Socket E10 2.2 LA TARJETA CPU08 2.2.1 Diagrama de bloques 2.2.2 Caractersticas 2.2.3 Programacin de la CPU08 2.3 EL PLC DL05 DE KOYO 2.3.1 Diagrama de bloques 2.3.2 Caractersticas 2.3.3 Modos de operacin 2.3.4 Mapa de memoria 2.3.5 Comunicacin 2.3.6 Programacin 2.4 CONTROLADORES 452 PLUS 2.4.1 Definicin de caracteres especiales 2.4.2 Protocolo de Comunicacin

27 27 28 28 29 31 34 36 37 39 40 41 42 42 43 44 44 45 45 46 47 49 49 50 50

2.4.2.1 Nivel 1 El Wrapping 2.4.2.2 Nivel 2 Contenido del mensaje 2.4.3 Contenido de posiciones anlogas del controlador 452 Plus

51 51 52 53 54 55 56 59 63 66 67 70 71

3. DESCRIPCIN DEL SOFTWARE

3.1 DESARROLLO DE UN SERVIDOR MODBUS/TCP 3.1.1 Estructura de Clases 3.1.2 Descripcin de las Clases 3.1.3 Ejemplo de cdigo fuente 3.2 DESARROLLO DE UN SERVIDOR WEB 3.3 DESARROLLO DE UNA INTERFAZ PARA ACCESO WEB 3.3.1 El applet como un cliente Modbus/TCP 3.3.2 Sistema de acceso 3.3.3 Panel de Control

3.4 IMPLEMENTACIN DE UN ESCLAVO MODBUS EN LA CPU08 73 3.4.1 Algoritmo de la aplicacin para la CPU08 3.4.2 La UART implementada por software 3.5 LA CPU08 MAESTRO DE UNA RED DE CONTROLADORES 3.5.1 Respuestas del controlador 452 Plus a solicitudes 3.5.2 Ejemplos de mensajes de lectura y escritura 74 79 80 81 83

3.6 CONFIGURACION DEL PLC DL05 COMO ESCLAVO MODBUS 84 3.7 CONFIGURACION DE LOS CONTROLADORES 452 PLUS 3.7.1 Conexiones fsicas 86 88 89 93 95

4. CONCLUSIONES BIBLIOGRAFA ANEXO

LISTA DE TABLAS

Pag. Tabla 1.1 Estructura del prefijo de Modbus/TCP Tabla 1.2 Estructura de mensajes en Modbus/TCP Tabla 1.3 Comandos de la Clase 0 Tabla 1.4 Comandos de la Clase 1 Tabla 1.5 Comandos Clase 2 Tabla 1.6 Funciones dependientes de la mquina Tabla 2.1 Modos de operacin del PLC DL05 Tabla 2.2 Tipos de memoria del PLC DL05 Tabla 2.3 Caractersticas del puerto 1 del PLC DL05 Tabla 2.4 Caractersticas del puerto 2 del PLC DL05 Tabla 2.5 Caracteres especiales ASCII del controlador Tabla 2.6 Tipos de mensaje del controlador 452 Plus Tabla 2.7 Posiciones de memoria del controlador 452 Plus Tabla 3.1 Pines utilizados por la tarjeta CPU08 Tabla 3.2 Caracteres de error del controlador 452 Plus Tabla 3.3 Ejemplo de trama de lectura del controlador 452 Plus Tabla 3.4 Ejemplo de trama de escritura del controlador 452 Plus Tabla 3.5 Variables de configuracin del PLC DL05 Tabla 3.6 Funciones MODBUS soportadas por el PLC DL05 Tabla 3.7 Configuracin de los controladores 452 Plus Tabla 3.8 Interfaz serial del controlador 452 Plus 15 16 18 19 19 20 46 47 48 48 50 52 52 77 81 83 84 84 86 87 88

LISTA DE FIGURAS

Pag. Figura 1.1. Diagrama de la red implementada Figura 1.2 Esquema de encapsulacin en Modbus/TCP Figura 2.1 La TINI como un conversor de protocolos Figura 2.2 Esquema del hardware de la TINI Figura 2.3 Mapa de memoria de la TINI Figura 2.4 Esquema del software de la TINI Figura 2.5 Diagrama de bloques de la CPU08 Figura 2.6 Diagrama de bloques del PLC DL05 Figura 3.1 Modelo cliente / servidor Figura 3.2 Estructura de clases Figura 3.3 Estructura de la interface de transporte Figura 3.3 Programa en Java de un servidor Modbus/TCP Figura 3.4 Ejemplo de cdigo para un servidor Web Figura 3.5 Archivo HTML que carga la applet en un navegador Web Figura 3.6 Cdigo en Java para un cliente Modbus/TCP Figura 3.7 Interfaz del Sistema de Acceso Figura 3.8 Vista del panel de control Figura 3.9 Algoritmo para el programa de la CPU08 Figura 3.10 Lectura de bits en la UART implementada Figura 3.11 Configuracin del puerto 2 en DirectSOFT 4 17 31 32 34 38 42 44 54 55 56 60 64 65 69 71 72 75 80 85

UNIVERSIDAD DEL VALLE

FACULTAD DE INGENIERA

Programa acadmico de pregrado de INGENIERA ELECTRNICA

Ttulo: Implementacin de una red Modbus/TCP Autor: Andrs Felipe Ruz Olaya Directores: Ing. Fabio Germn Guerrero, M. Sc. Ing. Asfur Barandica Lpez Grupo de investigacin: Percepcin y Sistemas Inteligentes. Area de investigacin: Comunicaciones Industriales. Descriptores: Modbus, Modbus/TCP, Ethernet, TCP/IP, Java, Interfaz Web, Instrumentacin, comunicaciones.

0. INTRODUCCION

En el rea de las comunicaciones en entornos industriales, la estandarizacin de protocolos es un tema en permanente discusin, donde intervienen problemas tcnicos y comerciales. Cada protocolo est optimizado para diferentes niveles de automatizacin y en consecuencia responden al inters de diferentes proveedores. Por ejemplo Fieldbus Foundation, Profibus y HART, estn diseados para instrumentacin de control de procesos. En cambio DeviceNet y SDC estn optimizados para los mercados de los dispositivos discretos (on-off) de detectores, actuadores e interruptores, donde el tiempo de respuesta y repetibilidad factores crticos1. son

Cada protocolo tiene un rango de aplicacin; fuera del mismo disminuye el rendimiento y aumenta la relacin costo/prestacin.

Tomado de Comunicaciones en entornos industriales, por Mario Distfano. Visitar la direccin http://fing.uncu.edu.ar/investigacion/institutos/IAEI/Cursos2.htm

Debido a la no aceptacin de un protocolo estndar nico en las comunicaciones industriales, los mltiples buses de campo han perdido terreno ante la incursin de tecnologas de comunicacin emergentes como Ethernet en este rea.

La aceptacin mundial de Ethernet en los entornos administrativos y de oficina ha generado el deseo de expandir su aplicacin a la planta. Ethernet se est moviendo rpidamente hacia el mercado de los sistemas de control de procesos y la automatizacin, para la interconexin a nivel de campo de sensores y actuadores, de esta forma reemplazando a los buses de campo en las industrias. Es posible que con los avances de Ethernet y la tecnologa emergente Fast Ethernet se pueda aplicar tambin al manejo de aplicaciones crticas de control2.

Los buses de campo son una forma especial de LAN dedicada a aplicaciones de adquisicin de datos y comando de elementos finales de control sobre la planta. Los buses de campo tpicamente operan sobre cables de par trenzado de bajo costo. A diferencia de Ethernet, donde no se puede garantizar determinismo sobre la llegada de paquetes, los diseadores optimizan los buses de campo para el intercambio de mensajes cortos de comando y de control con altsima seguridad y temporizacin estricta.

Tomado de Moving Ethernet to plant floors, por Sam Malizia. Visitar http://www.isa.org/journals/ic/feature/1,1162,541,00.html

la direccin

En las aplicaciones industriales, Ethernet es usado en conjunto con la pila de protocolos TCP/IP universalmente aceptada. TCP/IP es el conjunto de protocolos usado en Internet, suministrando un mecanismo de transporte de datos confiable entre mquinas y permitiendo interoperabilidad entre diversas plataformas. Usar TCP/IP sobre Ethernet a nivel de campo en la industria permite tener una verdadera integracin con la Intranet corporativa, y de esta forma se ejerce un estricto control sobre la produccin3.

En este proyecto se pretende utilizar un estndar de instrumentacin sobre Ethernet, Modbus/TCP4, para realizar la implementacin de una red de control industrial capaz de ser accedida a travs de lnternet la Intranet local, usando los protocolos TCP/IP. El protocolo Modbus/TCP es muy difundido por ser abierto, lo cual le permite la comunicacin con gran diversidad de elementos industriales; es por eso que es de gran importancia trabajar sobre l, y adems debido a que en nuestro medio no se encuentran desarrollos concernientes a este tema.

Arquitectura de la solucin El siguiente diagrama ilustra la red Modbus/TCP implementada, al igual que los enlaces y la interaccin que debe existir entre los diversos elementos que componen el sistema :

3
4

Tomado de http://www.modbus.org/modbus_tcp_new.htm El protocolo Modbus/TCP fue introducido por Schneider Automation. La especificacin se encuentra disponible en http://www.modicon.com/openmbus.

Figura 1.1 Diagrama de la red implementada

El sistema planteado se centra en torno a la tarjeta TINI5 (Tiny InterNet Interface) la cual provee el acceso Ethernet. Esta tarjeta es programable en Java y posee un sistema operativo propio, el cual contiene la pila de protocolos TCP/IP para el desarrollo de aplicaciones de red.

Objetivo general

Recopilar informacin y adquirir el conocimiento necesario para implementar, configurar, mantener y evaluar una red Modbus/TCP.

Objetivos especficos

!" Implementar en la tarjeta TINI un servidor Modbus/TCP,

el cual permita a

travs de este protocolo supervisar y comandar elementos finales de control.

!" Implementar en la tarjeta TINI un servidor Web, el cual permita controlar y

monitorear los elementos que conforman la red.

!" Programar la tarjeta CPU08 , para que pueda comportarse como un esclavo

MODBUS, y a la vez como un maestro de una red RS-485 de controladores.

5 6

Para ms informacin de esta tarjeta, consultar la seccin 2.1. Para ms informacin de esta tarjeta, consultar la seccin 2.2.

!" Implementar un esclavo MODBUS en la tarjeta TINI.

!" Desarrollar una interfaz de usuario grfica va Web, desde la cual sea posible realizar operaciones remotamente de supervisin y control sobre los distintos elementos de la red Modbus/TCP.

!" Integrar y colocar en funcionamiento los distintos elementos que conforman la red a implementar. Adems debe demostrarse la interoperabilidad de la red probndola con software de diferentes vendedores.

El presente trabajo se encuentra dividido en diversas partes que abarcan las etapas en las cuales se desarroll el proyecto.

En la primera parte El protocolo Modbus/TCP, se expone en profundidad dicho estndar y se detalla la manera en que se lleva a cabo su implementacin. Aqu tambin se presentan las ventajas del protocolo y las caractersticas que proporciona para ser usado en comunicaciones industriales sobre Ethernet.

En la segunda parte Descripcin del hardware, se presenta en detalle las caractersticas de cada uno de los elementos que conforman la red Modbus/TCP implementada y el papel que desempean en el sistema completo. Se realiza una

exposicin exhaustiva de la tarjeta TINI, ya que en ella reside gran parte de la funcionalidad que proporciona la red Modbus/TCP.

En la tercera parte Descripcin del software, se describe la forma en que se desarrollaron los programas y aplicaciones que corren sobre los diversos elementos de la red, adems se explica la funcionalidad que brindan y la interaccin entre los diversos componentes de software.

Finalmente, en la ultima parte se exponen los resultados y conclusiones del proyecto y el trabajo futuro para con la red implementada.

1. EL PROTOCOLO MODBUS/TCP7

1.1 DESCRIPCION

Modbus/TCP es un protocolo de comunicacin diseado para permitir a equipo industrial tal como Controladores Lgicos Programables (PLCs), computadores, motores, sensores, y otros tipos de dispositivos fsicos de entrada/salida comunicarse sobre una red. Modbus/TCP fue introducido por Schneider Automation como una variante de la familia MODBUS ampliamente usada, los protocolos de comunicacin simples y abiertos, destinados para la supervisin y el control de equipo de automatizacin. Especficamente, el protocolo cubre el uso de mensajes MODBUS en un entorno Intranet o Internet usando los protocolos TCP/IP8.

7 8

Parte de esta seccin es tomado de la especificacin en http://www.modicon.com/openmbus Tomado de http://www.modbus.org

La especificacin Modbus/TCP define un estndar interoperable en el campo de la automatizacin industrial, el cual es simple de implementar para cualquier dispositivo que soporta sockets9 TCP/IP.

1.1.1 Orientado a conexin.

MODBUS es un protocolo de comunicacin sin estado, es decir, cada solicitud del maestro es tratada independientemente por el esclavo y es considerada una nueva solicitud no relacionada a las anteriores, de esta forma haciendo a las transacciones de datos altamente resistentes a rupturas debido a ruido y adems requiriendo mnima informacin de recuperacin para ser mantenida la transaccin en cualquiera de los dos terminales .

Las operaciones de programacin de otro lado, esperan una comunicacin orientada a la conexin, es decir, las mquinas de origen y de destino establecen un canal de comunicaciones antes de transferir datos. Este tipo de operaciones son implementadas de diferentes maneras por las diversas variantes de MODBUS (Modbus RTU, Modbus ASCII, Modbus PLUS).

Un socket es una abstraccin proporcionada por el sistema operativo que permite a un programa de aplicacin accesar los protocolos TCP/IP.

10

Modbus/TCP

maneja

ambas

situaciones.

Una

conexin

es

inicialmente

establecida en esta capa de protocolo (nivel de aplicacin), y esa conexin nica puede llevar mltiples transacciones independientes.

En adicin, TCP permite establecer un gran nmero de conexiones concurrentes, de este modo el cliente (maestro) puede ya sea re-usar una conexin

previamente establecida crear una nueva, en el momento de realizar una transaccin de datos.

Es interesante analizar porqu el protocolo TCP orientado a la conexin es usado en lugar del protocolo UDP10 orientado a datagramas. La principal razn es mantener control de una transaccin individual encerrndola en una conexin la cual pueda ser identificada, supervisada, y cancelada sin requerir accin especfica de parte de las aplicaciones cliente y servidor. Esto da al mecanismo una amplia tolerancia a cambios del desempeo de la red, y permite que herramientas de seguridad tal como firewalls11 y proxies puedan ser fcilmente aadidos.

10

El UDP (User Datagram Protocol) proporciona un servicio de entrega sin conexin, utilizando el IP para transportar mensajes entre mquinas. Emplea el IP para llevar mensajes, pero agrega la capacidad para distinguir entre varios destinos dentro de una mquina host. 11 Un firewall (muro de seguridad) se le dice a una configuracin de ruteadores y redes colocados entre la organizacin interna de una red y su conexin con redes externas a fin de dar seguridad.

11

1.1.2 Codificacin de datos.

MODBUS usa una representacin big-endian12 para direcciones y datos. Esto significa que cuando una cantidad numrica ms grande que un byte es transmitido, el byte ms significante es enviado primero. As, por ejemplo: 0x1234 ser 0x12 0x34

1.1.3 Interpretacin del modelo de datos.

MODBUS basa su modelo de datos sobre una serie de tablas las cuales tienen caractersticas distintivas. Las cuatro principales son:

!" Entradas discretas. Bit simple, suministrado por un sistema I/O, de solo lectura. !" Salidas discretas. Bit simple, alterable por un programa de aplicacin, de lectura-escritura. !" Registros de entrada. Cantidad de 16 bits, suministrado por un sistema I/O, de solo lectura. !" Registros de salida. Cantidad de 16 bits, alterable por un programa de aplicacin, de lectura-escritura.

12

Big-endian es un formato en el cual el byte ms significativo se encuentra primero.

12

La distincin entre entradas y salidas, y entre datos direccionables al bit y direccionables a la palabra, no implica algn comportamiento de la aplicacin. Es aceptable y comn, considerar las cuatro tablas sobrelapando una con otra, si esta es la interpretacin ms natural sobre la mquina (esclavo MODBUS) en cuestin.

1.1.4 Filosofa de longitud implicada.

Todas las solicitudes y respuestas MODBUS estn diseadas en tal forma que el receptor puede verificar que un mensaje est completo. Para cdigos de funcin donde la solicitud y respuesta son una longitud fija, el cdigo de funcin solo es suficiente. Para cdigos de funcin llevando una cantidad variable de datos en la solicitud respuesta, la porcin de datos estar precedida por un campo que representa el nmero de bytes que siguen.

Cuando MODBUS es llevado sobre TCP informacin de longitud se adiciona en el prefijo (o encabezado) para permitir al receptor reconocer los lmites del mensaje, igual si el mensaje ha sido dividido en mltiples paquetes para la transmisin. La existencia de reglas de longitud implcitas o explcitas, y el uso de un cdigo de chequeo de error CRC-3213 (sobre Ethernet) resulta en una probabilidad muy pequea de corrupcin no detectada sobre un mensaje de solicitud o respuesta.

13

CRC (Cyclic Redundancy Code), verificacin por redundancia cclica.

13

1.2 VENTAJAS DEL PROTOCOLO MODBUS/TCP

!" Es escalable en complejidad. Un dispositivo el cual tiene solo un propsito simple necesita solo implementar uno dos tipos de mensaje.

!" Es simple para administrar y expandir. No se requiere usar herramientas de configuracin complejas cuando se aade una nueva estacin a una red Modbus/TCP.

!" No es necesario equipo o software propietario de algn vendedor. Cualquier sistema computador microprocesador con una pila de protocolos TCP/IP puede usar Modbus/TCP.

!" Puede ser usado para comunicar con una gran base instalada de dispositivos MODBUS, usando productos de conversin los cuales no requieren configuracin.

!" Es de muy alto desempeo, limitado tpicamente por la capacidad del sistema operativo del computador para comunicarse. Altas ratas de transmisin son fciles de lograr sobre una estacin nica, y cualquier red puede ser construida para lograr tiempos de respuesta garantizados en el rango de milisegundos.

14

1.3 ESTRUCTURA DEL PROTOCOLO

A continuacin se describe la forma general de encapsulacin de una solicitud o respuesta MODBUS cuando es llevada sobre una red Modbus/TCP. Es importante anotar que la estructura del cuerpo de la solicitud y respuesta, desde el cdigo de funcin hasta el fin de la porcin de datos, tiene exactamente la misma disposicin y significado como en las otras variantes MODBUS, tal como:

MODBUS serial codificacin ASCII MODBUS serial codificacin RTU MODBUS PLUS Las nicas diferencias en esos otros casos son la especificacin de los delimitadores inicial y final del mensaje14, el patrn de chequeo de error y la interpretacin de la direccin.

Todas las solicitudes son enviadas va TCP sobre el puerto registrado 502. Las solicitudes normalmente son enviadas en forma half-duplex15 sobre una conexin dada. Es decir, no hay beneficio en enviar solicitudes adicionales sobre una nica conexin mientras una respuesta est pendiente. Sin embargo, los dispositivos

14 15

En MODBUS esto se denomina Framing. En half-duplex los datos pueden viajar en cualquier direccin, pero no en forma simultnea.

15

que desean obtener altas ratas de transferencia pueden establecer mltiples conexiones TCP al mismo destino.

El campo direccin esclavo de MODBUS es reemplazado por un byte identificador de unidad el cual puede ser usado para comunicar a travs de dispositivos tales como puentes y gateways, los cuales usan una direccin IP nica para soportar mltiples unidades terminales independientes.

Los mensajes de solicitud y respuesta en Modbus/TCP poseen un prefijo encabezado compuesto por seis bytes como se aprecia en la tabla 1.1. Tabla 1.1 Estructura del prefijo de Modbus/TCP ref ref 00 00 00 len

El ref ref anterior son los dos bytes del campo referencia de transaccin, un nmero que no tiene valor en el servidor pero son copiados literalmente desde la solicitud a la respuesta a conveniencia del cliente. Este campo se utiliza para que un cliente Modbus/TCP pueda establecer simultneamente mltiples conexiones con diferentes servidores y pueda identificar cada una de las transacciones.

El tercer y cuarto campo del prefijo representan el identificador de protocolo, un nmero el cual debe ser establecido a cero.

16

El len especifica el nmero de bytes que siguen. La longitud es una cantidad de dos bytes, pero el byte alto se establece a cero ya que los mensajes son ms pequeos que 256.

De esta forma, un mensaje Modbus/TCP completo posee una estructura como se muestra en la tabla 1.2.

Tabla 1.2 Estructura de mensajes en Modbus/TCP Posicin del Byte Byte 0 Significado Identificador de transaccin. Copiado por el servidor normalmente 0. Byte 1 Identificador de transaccin. Copiado por el servidor normalmente 0. Byte 2 Byte 3 Byte 4 Identificador de protocolo = 0. Identificador de protocolo = 0. Campo de longitud (byte alto) = 0.Ya que los mensajes son menores a 256. Byte 5 Campo de longitud (byte bajo). Nmero de bytes siguientes. Byte 6 Identificador de unidad (previamente direccin esclavo). Byte 7 Byte 8 y ms Cdigo de funcin MODBUS. Los datos necesarios.

17

1.4 ESQUEMA DE ENCAPSULACION

Modbus/TCP bsicamente embebe un marco MODBUS dentro de un marco TCP en una manera simple como es mostrado en la Figura 1.2.

Figura 1.2 Esquema de encapsulacin en Modbus/TCP

1.5 CONFORMACION DE CLASES

MODBUS por su naturaleza es ya implementada en muchsimos lugares, por tanto una ruptura de las implementaciones existentes debe ser evitada.

De esta forma el conjunto de los tipos de transaccin MODBUS existente ha sido clasificado en clases, donde el nivel 0 representa funciones las cuales son universalmente implementadas y totalmente consistentes, y el nivel 2 representa funciones tiles pero algo dependientes del esclavo. Esas funciones del conjunto, las cuales no son convenientes por interoperabilidad son tambin identificadas.

18

Debe anotarse que futuras extensiones al estndar pueden definir cdigos de funcin adicionales para manejar situaciones donde el estndar existente es deficiente.

1.5.1 Comandos Clase 0.

Este es el mnimo conjunto til de funciones, tanto para el maestro como para el esclavo.

Tabla 1.3 Comandos de la Clase 0 Cdigo 03 16 Funcin Leer mltiples registros holding16. Escribir mltiples registros holding.

1.5.2 Comandos Clase 1.

Este es el conjunto adicional de funciones, el cual es comnmente implementado e interoperable. Como fue explicado antes, muchos esclavos deciden tratar entradas, salidas, registros, y valores discretos como equivalentes.

En el protocolo MODBUS , holding register representa una cantidad de 16 bits, la cual representa una posicin interna de la memoria.

16

19

Cdigo 01 02 04 05 06 07

Tabla 1.4 Comandos de la Clase 1 Funcin Leer estado de salidas discretas. Leer estado de entradas discretas. Leer registros de entrada. Forzar una salida discreta. Prefijar un registro holding nico. Leer estados de excepcin*.

* Esta funcin tpicamente tiene un significado diferente para cada familia de esclavos.

1.5.3 Comandos Clase 2.

Estas son las funciones de transferencia de datos necesarias para operaciones de rutina tal como supervisin y HMI17.

Cdigo 15 20 21 22 23 24

Tabla 1.5 Comandos Clase 2 Funcin Fijar mltiples salidas discretas. Leer referencia general*. Escribir referencia general*. Enmascarar registro de escritura. Leer/escribir registros**. Leer cola FIFO***.

* Esta funcin ser la ms apropiada para manejar grandes espacios de registros y datos, los cuales carecen de nmeros de referencia. ** Esta funcin permite la entrada y salida de un rango de registros como una transaccin nica. Es la forma ms eficiente usando MODBUS para desempear un intercambio regular de datos tal como con un mdulo I/O. *** Una funcin algo especializada, destinada a permitir la transferencia de datos desde una tabla estructurada como una FIFO a un computador.
17

HMI : Human Machine Interface.

20

1.5.4 Comandos especficos de la mquina/red/vendedor

Todas de las siguientes funciones, aunque mencionadas en los manuales del protocolo MODBUS, no son apropiadas para propsitos de interoperabilidad porque ellas son dependientes de la mquina.

Tabla 1.6 Funciones dependientes de la mquina Cdigo 08 09 10 11 12 13 14 17 18 19 125 126 127 Programacin*. Completar la programacin*. Leer la palabra de estado del contador de eventos. Leer el registro de eventos de comunicacin. Programacin**. Completar la programacin**. Reportar ID del esclavo. Programacin***. Reinicializar enlace de comunicaciones***. Sustitucin de firmware. Programacin**. Reportar direccin local. Funcin Pruebas de diagnstico.

* Soportada solo por controladores 484 de Modicon. ** Soportada solo por controladores 584/984 de Modicon. *** Soportada solo por controladores 884 y Micro84de Modicon.

21

1.6 DESEMPEO REQUERIDO Y ESPERADO

No existe una especificacin precisa acerca del tiempo de respuesta requerida para una transaccin sobre MODBUS Modbus/TCP.

Esto es debido a que se espera que Modbus/TCP sea usado en la ms amplia variedad posible de situaciones de comunicacin, desde sistemas I/O esperando temporizacin en milisegundos, a enlaces de radio de larga distancia con retardos de varios segundos.

En general, los dispositivos tales como PLCs respondern a solicitudes ingresantes en un tiempo scan18, el cual tpicamente vara entre 20 y 200 msg.

Desde la perspectiva del cliente, ese tiempo de respuesta debe ser extendido por los retardos de transporte travs de la red, a un tiempo de respuesta razonable. Tales retardos pueden ser de milisegundos para un Ethernet conmutado, a cientos de milisegundos para una conexin de red de rea amplia (WAN).

Cualquier tiempo timeout19 usado en un cliente debe ser ms grande que el mximo tiempo de respuesta razonable, para as evitar una excesiva congestin en el dispositivo servidor en la red, lo cual puede causar errores.

18 19

Un tiempo scan, es el tiempo requerido para que el PLC complete sus instrucciones programadas. Un timeout es un tiempo que se establece antes de que se reporte un fallo.

22

As en la prctica, los timeouts usados en aplicaciones cliente de alto desempeo sern probablemente algo dependientes sobre la topologa de la red y el desempeo esperado del servidor. Aplicaciones cliente las cuales no son crticas en tiempo pueden con frecuencia dejar los valores timeout al establecido por defecto en TCP, el cual reportar fallo en la comunicacin despus de varios segundos.

Los clientes pueden cerrar y re-establecer conexiones Modbus/TCP cuando el timeout ha expirado. Sin embargo al retransmitir una solicitud, es aconsejable establecer el timeout un poco ms grande que el anterior, para as permitir a un servidor recuperarse de un posible error.

1.7 GUIA DE IMPLEMENTACION DEL CLIENTE Y SERVIDOR

El contenido de esta seccin no ser considerado obligatorio para la implementacin particular de un cliente servidor. Sin embargo, si son seguidas, estas polticas facilitarn la integracin cuando se implementen sistemas multivendedor y gateways a equipo MODBUS ya instalado.

1.7.1 Diseo del Cliente.

Modbus/TCP est diseado para permitir que el diseo de un cliente sea tan simple como sea posible. El proceso bsico de manejo de una transaccin es como sigue:

23

!" Establecer una conexin TCP al puerto 50220 en el destino (servidor) deseado.

!" Preparar una solicitud MODBUS, codificada como fue descrito antes.

!" Enviar la solicitud MODBUS, incluyendo su prefijo Modbus/TCP de 6 bytes, como un nico buffer transmitido.

!" Esperar que una respuesta aparezca sobre la misma conexin TCP. Opcionalmente correr un timeout, si se desea ser avisado de problemas de comunicacin ms rpido de lo que TCP normalmente reporta.

!" Leer los primeros 6 bytes de la respuesta, el cual indicar la longitud real del mensaje recibido.

!" Leer los bytes restantes de la respuesta.

!" Si no se espera una comunicacin adicional al destino particular en el futuro inmediato, cerrar la conexin TCP as que los recursos en el servidor puedan ser usados, si es requerido, para servir a otros clientes. Un tiempo de un segundo es sugerido como el perodo mximo para dejar una conexin abierta en el cliente.

Un puerto de protocolo es una abstraccin que los protocolos de transporte del TCP/IP utilizan para distinguir entre varios destinos en una computadora host especfica.

20

24

En el evento que expire el timeout para una respuesta, realizar un cierre unilateral de la conexin, abrir una nueva, y re-enviar la solicitud. Esta tcnica permite al cliente control sobre la temporizacin de re-intentos, el cual es superior al suministrado por defecto por TCP. Tambin permite el uso de estrategias alternas, tal como enviar la solicitud a una direccin IP alterna, usando una red de comunicacin totalmente independiente, en caso de fallo de un componente de la infraestructura de la red.

1.7.1 Diseo del Servidor.

Un servidor Modbus/TCP siempre ser diseado para soportar mltiples clientes concurrentes, sin importar que en su uso previsto solo un nico cliente parezca tener sentido. Esto permite al cliente cerrar y reabrir la conexin a fin de responder rpidamente a la no entrega de una respuesta.

Si una pila de protocolos TCP/IP convencional es usada, considerables recursos de memoria pueden ser ahorrados reduciendo el tamao de los buffers de transmisin y recepcin. Un servicio TCP normal usualmente asignar 8K bytes ms como un buffer de recepcin por conexin. Tal espacio de buffer no tiene valor en Modbus/TCP, ya que el tamao mximo de una solicitud respuesta es menor que 300 bytes. De esta forma se liberan recursos para conexiones adicionales.

25

Los sistemas operativos lenguajes que fomentan el uso de mltiples threads (hilos de control), tal como Java, pueden usar la estrategia multithreaded, descrita a continuacin :

1. Esperar conexiones entrantes sobre el puerto 502 de TCP.

2. Cuando una nueva solicitud de conexin sea recibida, aceptarla y crear un nuevo thread para manejar la conexin.

3. Dentro del nuevo thread, hacer lo siguiente en un lazo infinito :

!" Leer el encabezado de 6 bytes de la solicitud Modbus/TCP. No colocar un timeout aqu, pero en cambio esperar hasta ya sea que llegue la solicitud la conexin sea cerrada. Ambas situaciones despertarn al thread

automticamente.

!" Analizar el encabezado. Si aparece corrupto, por ejemplo si el campo de protocolo no es cero la longitud del mensaje es ms grande que 256, entonces cerrar unilateralmente la conexin. Esta es la respuesta correcta de un servidor a una situacin donde la codificacin TCP es incorrecta.

!" Leer los bytes restantes del mensaje, cuya longitud es ahora conocida.

26

!" Procesar el mensaje MODBUS que ingres, si es necesario suspendiendo el thread corriente hasta que la respuesta correcta pueda ser calculada. Eventualmente se tendr ya sea un mensaje MODBUS vlido un mensaje de excepcin para usar como una respuesta.

!" Generar el prefijo Modbus/TCP para la respuesta, copiando el campo identificador de transaccin desde la solicitud, y recalculando el campo de longitud.

!" Enviar la respuesta, incluyendo el prefijo Modbus/TCP como un buffer nico para transmisin sobre la conexin establecida.

!" De nuevo volver a esperar el prximo prefijo de 6 bytes, y repetir el procedimiento.

Eventualmente, cuando el cliente elija cerrar la conexin, la recepcin del prefijo de 6 bytes fallar. En este caso se cierra la conexin y se cancela el thread corriente.

27

2. DESCRIPCION DEL HARDWARE

La red Modbus/TCP que se implementa en este proyecto, ver Figura 1.1, se encuentra conformada por diversos elementos hardware, incluyendo los elementos finales de control. A continuacin se enumeran los componentes que integran la red:

1. Tarjeta TINI. 2. Tarjeta CPU08. 3. PLC DL05 de Koyo. 4. Controladores 452 PLUS.

2.1 LA TARJETA TINI21

La tarjeta TINI es un sistema embebido para la cual se desarrollarn las siguientes aplicaciones: un servidor Modbus/TCP, un servidor Web y el software para actuar como gateway de otros esclavos, como el PLC DL05 y la tarjeta CPU08.

21

Tomado de The TINI Specification and Developer`s Guide, por Don Loomis. Addison Wesley, 2001.

28

2.1.1 Descripcin.

La Tiny InterNet Interface (TINI) es una plataforma desarrollada por Dallas Semiconductor que suministra un medio simple, flexible y econmico para disear una extensa variedad de dispositivos hardware capaces de conectarse directamente a redes corporativas y locales. Las caractersticas de la plataforma son expuestas al desarrollador de software a travs de un set de interfaces de programacin de aplicaciones (APIs) en Java, brindando un poderoso entorno de programacin orientado a objetos y facultando al programador en la creacin de aplicaciones utilizando la potencia y bondades que ofrece el lenguaje Java.

La plataforma TINI permite a dispositivos como sensores y actuadores ser monitoreados, controlados y manejados remotamente. Esta capacidad de

interconectividad de red de la TINI permite a cualquier dispositivo conectado a ella, una interaccin con sistemas remotos y usuarios a travs de aplicaciones de red estndar, tal como browsers Web.

2.1.2 Caractersticas.

La TINI es una tarjeta SIMM (31.8mm x 102.9mm) de 72 pines. Es una implementacin hardware con Ethernet y soporta toda la funcionalidad suministrada por cualquier sistema embebido. La tarjeta incluye las siguientes caractersticas:

29

!" 512 Kilobytes de memoria flash para cdigo del sistema crtico. !" 512 Kilobytes de memoria SRAM no-voltil, expandible a 1 Megabyte. !" Controlador Ethernet 10Base-T. !" Reloj de tiempo real. !" Doble puerto serial (uno con niveles RS-232 y otro con niveles TTL). !" Doble controlador CAN. !" Doble interfaz de red 1-Wire. !" Expone los buses de datos y direcciones del microcontrolador para expansin paralela. !" Requiere una fuente de alimentacin nica de 5V DC. !" El sistema operativo es actualizado constantemente y puede ser cargado directamente a la memoria flash.

2.1.3 Aplicaciones.

La TINI est diseada para satisfacer los requerimientos de las aplicaciones de red embebidas tanto industriales como comerciales. Sin embargo, a causa de su bajo costo y la disponibilidad de herramientas de desarrollo de software gratuito, tambin est incursionando en el hogar y en entornos educativos. La TINI puede ser usada para tareas embebidas tradicionales stand-alone, pero la mayora de aplicaciones utilizan las capacidades de interconectividad de la tarjeta. Unas pocas aplicaciones de la tecnologa TINI incluyen las siguientes:

30

!" Monitoreo y control de equipo basado en Web. La TINI puede ser usada para establecer comunicacin con equipos especficos, para proveer recoleccin de datos y diagnstico remoto para propsitos tales como el monitoreo sobre la utilizacin de un dispositivo particular.

!" Conversin de protocolos. Los sistemas basados en la TINI pueden ser usados para conectar dispositivos a redes Ethernet. Esto puede ser hecho con un PC, sin embargo la TINI hace el trabajo en una fraccin del costo y del tamao.

!" Sistemas de medicin remota. Es posible construir aplicaciones para medicin distribuidas en una red. La TINI estara equipada con dispositivos de medicin como servidor que se controla desde un cliente remoto.

!" Control industrial. Utilizando el soporte integrado de la TINI, como el bus CAN (Controller Area Network) para llevar a cabo la automatizacin de equipo.

!" Monitores ambientales. Usando el soporte construido en la TINI de interconexin 1-Wire, una aplicacin puede interrogar a sensores y reportar los resultados a hosts remotos.

La Figura 2.1 muestra un modelo de uso en el cual la TINI es empleada como un conversor de protocolos ( enlaces) entre un dispositivo embebido y una red Ethernet.

31

Figura 2.1 La TINI como un conversor de protocolos

El dispositivo embebido puede comunicar con el mundo exterior usando un puerto serial RS-232, un puerto CAN, quizs algn tipo de interfaz paralela.

La aplicacin Java corriendo sobre la TINI desempea la tarea de comunicacin con el dispositivo en su lenguaje nativo (usando un protocolo de comunicacin especfico del dispositivo) y presenta los resultados a sistemas remotos alcanzables a travs de una red TCP/IP. El enlace suministrado por la TINI es bidireccional, permitiendo a un sistema remoto controlar el dispositivo.

2.1.4 Hardware de la TINI.

La TINI esta desarrollada con diversos chips LSI. Un esquema del hardware que compone la TINI es presentado en la Figura 2.2.

32

Figura 2.2 Esquema del hardware de la TINI

La TINI est compuesta principalmente de los siguientes elementos:

!" Microcontrolador. !" Memoria flash. !" Memoria RAM esttica.

El corazn de la TINI es el microcontrolador DS80C390 de Dallas Semiconductor. El DS80C390 integra soporte para diversas formas de I/O incluyendo puertos seriales, enlace 1-Wire y bus CAN. El microcontrolador tambin provee distintos pines de propsito general que pueden ser usados para desempear tareas de control simples tales como manejar rels y LEDs de estatus.

33

La memoria flash almacena el entorno runtime22 de la TINI y satisface los siguientes dos requerimientos importantes:

1. El contenido de memoria es mantenido, igual en ausencia de potencia al sistema. 2. La memoria es reprogramable, y por tanto el entorno runtime puede ser actualizado cuando sea requerido.

La memoria RAM esttica contiene el rea de datos, la pila (heap), al igual que los archivos de datos del sistema. La SRAM es no-voltil, ya que posee una circuitera con batera de respaldo de forma que el contenido de la memoria persiste en ausencia de alimentacin. La batera es una muy pequea celda de litio.

Otros dispositivos perifricos, aparte de la memoria, pueden tambin ser interfazados directamente a los buses de datos y direcciones del microcontrolador (denominada expansin I/O paralela en la Figura 2.2). Dos de tales perifricos usados en el sistema TINI son un controlador Ethernet y un reloj en tiempo real. Esta configuracin extiende el alcance de los dispositivos embebidos a redes Ethernet y provee una referencia exacta de tiempo para propsitos especficos.

La batera de respaldo tambin mantiene corriendo el reloj en ausencia de potencia, asegurando que un tiempo exacto es siempre ledo desde el reloj.

22

El entorno runtime esta compuesto por el sistema operativo y la Mquina Virtual Java (JVM).

34

2.1.5 Mapa de memoria del sistema.

Un mapa de memoria especifica dnde la memoria y otros dispositivos perifricos son decodificados en el espacio de direcciones del microcontrolador. El mapa de memoria utilizado por la TINI, mostrado en la Figura 2.3, consiste de los siguientes tres segmentos:

!" Segmento de cdigo. !" Segmento de datos. !" Segmento de perifricos.

Figura 2.3 Mapa de memoria de la TINI

35

La figura ilustra los mximos tamaos de segmento soportados por la TINI. La direccin de inicio del segmento es siempre constante, mientras la direccin final puede variar de acuerdo al tamao de memoria.

La TINI consume los siguientes rangos de direcciones:

1. TINI OS y Java API: [ 0x000000 0x07FFFF ] 2. Heap y almacenaje del sistema de archivos: [ 0x180000 0x280000 ] 3. Controlador Ethernet: [ 0x300000 0x37FFFF ] 4. Reloj de tiempo real: [ 0x310000 ]

Los diseadores deben evitar los rangos del controlador Ethernet y el reloj, cuando se adicionen otros dispositivos perifricos.

Existe tambin un rea perifrica separada, de 4 Megabytes, conocida como espacio PCE (Peripheral Chip Enable), que puede ser usada para interfazar grandes chips de memoria externa otros dispositivos directamente a los buses de datos y direcciones del microcontrolador.

Sin embargo, la mayora de hardware es mapeado en el segmento perifrico porque el microcontrolador puede accesarlo ms eficientemente.

36

2.1.6 Sistema I/O integrado.

Un amplio rango de dispositivos no soportan la interfaz a un bus perifrico. Frecuentemente esos dispositivos tienen alguna forma de interfaz serial. Un soporte para los siguientes protocolos de comunicacin serial han sido integrados dentro del microcontrolador.

!" Comunicacin serial. Son soportados protocolos seriales sncronos, utilizando una interfaz de 2 alambres, y comunicacin serial asncrona, basada en el estndar RS-232. El microcontrolador de la TINI provee dos circuitos UART (Universal Asynchronous Receiver Transmitter) integrados, que facilitan la comunicacin.

!" Bus CAN. Originalmente desarrollado en Bosch-Siemens, CAN est ahora descrito en dos estndares ISO. CAN suministra un bus de comunicaciones serial confiable que es comnmente usado en aplicaciones de control industrial y automotriz. El microcontrolador de la TINI provee dos controladores CAN integrados.

!" Red 1-Wire. Desarrollado por Dallas Semiconductor, el enlace 1-Wire es una red de pequeos sensores, actuadores, y elementos de memoria en que todos comparten el mismo conductor tanto para comunicacin como para potencia.

37

!" I/O TTL. Los pines de propsito general del puerto del microcontrolador pueden ser usados para diversas tareas de control y no estn necesariamente atados a algn tipo de dispositivo serial.

La utilizacin de las capacidades I/O integradas en el microcontrolador en lugar de I/O mapeada en memoria, reduce el costo de la comunicacin con un dispositivo externo porque se libera a la CPU de operaciones de lectura y escritura de datos a un dispositivo perifrico.

2.1.7 Software de la TINI.

Aparte del hardware esencial para el desarrollo de aplicaciones de red embebidas, una gran cantidad de software es tambin suministrado con la TINI para liberar a los desarrolladores de aplicacin de tener que preocuparse acerca de los detalles de la creacin de capas de infraestructura que den soporte para la ejecucin de tareas mltiples, pilas de protocolos de red e interfaces de programacin de aplicaciones. Un entorno bien definido que suministre todas de esas

caractersticas permite al desarrollador enfocarse principalmente sobre los detalles de la aplicacin. De esta forma, un entorno runtime fue desarrollado como parte integral de la plataforma TINI. Una representacin grfica del entorno runtime es mostrada en la Figura 2.4.

38

Figura 2.4 Esquema del software de la TINI

El software que comprende el entorno runtime de la TINI puede ser dividido en dos categoras: un sistema operativo el cual es ejecutado directamente por el microcontrolador y un API interpretado como bytecodes por la Mquina Virtual de Java (JVM).

El cdigo de las aplicaciones corriendo sobre la tarjeta TINI son escritos en Java y utilizan el API, siendo esto uno de los principales atractivos de la tarjeta.

39

Java es un lenguaje de programacin simple, poderoso, concurrente, orientado a objetos, con capacidades cliente/servidor, con el cual se pueden crear programas interactivos, seguros, portables, robustos y para cualquier tipo de arquitectura.

Es posible escribir tambin libreras nativas que pueden ser cargadas desde una aplicacin para lograr requerimientos estrictos de tiempo real.

2.1.8 Sistema operativo de la TINI.

El sistema operativo de la TINI es la capa ms baja del entorno runtime. Es responsable de la administracin de todos los recursos del sistema incluyendo el acceso a la memoria, planificacin de procesos mltiples y threads de ejecucin, y la interaccin con componentes hardware internos y externos. A excepcin del recolector de basura23, todas las tareas manejadas por el sistema operativo son aplicaciones Java.

Los tres componentes principales que conforman el sistema operativo son:

!" Planificador de procesos y threads. !" Subsistema de manejo de memoria. !" Subsistema de manejo de I/O.

El recolector de basura (Garbage Collector) es un hilo que Java provee, el cual automticamente recupera la memoria dinmicamente repartida que ya no se necesita, liberando a los programadores de incluir enunciados en los programas para ejecutar esta accin.

23

40

Tanto la pila TCP/IP como el manejador de I/O son implementados como procesos del kernel independientes. La pila de protocolo de red TCP/IP provee mucha de la misma capacidad de interconectividad encontrada sobre plataformas ms grandes y es suficientemente rica en funcionalidad para soportar una implementacin completa del paquete java.net. La pila de protocolo soporta mltiples interfaces de red, incluyendo Ethernet, para interconexin de alta velocidad en rea local, y PPP (Point-to-Point Protocol) sobre un enlace serial para interconexin remota usando modem.

2.1.9 El Socket E10.

El Socket E10 es una tarjeta de 160mm x 120mm, cuya funcin principal es proveer los conectores fsicos para interfazar la TINI a Ethernet, dispositivos seriales, alimentacin. La tarjeta Socket E10 est destinada a ayudar en el proceso de desarrollo de aplicaciones y suministra los siguientes conectores fsicos:

!" Conector SIMM de 72 pines. El conector SIMM acepta la tarjeta TINI.

!" Conector DB9 hembra. Este conector provee un puerto serial tipo DCE (Data Communications Equipment) que da conexin a un puerto serial DTE (Data Terminal Equipment) estndar. Este puerto es tpicamente usado slo para cargar el software a la memoria flash de la TINI.

41

!" Conector DB9 macho. Este conector provee un puerto serial DTE para conexin a dispositivos DCE tal como modems. Muchas aplicaciones TINI que controlan dispositivos seriales usan el puerto DTE.

!" Conector RJ45. El conector RJ45 acepta un cable Ethernet estndar 10Base-T suministrando conectividad a una red Ethernet.

!" Conector RJ11. El conector RJ11 provee acceso a la red 1-Wire usando cable telefnico estndar.

!" Jack de potencia. El Socket E10 acepta una fuente de alimentacin de 5V DC.

El Socket E10 tambin suministra el espacio respectivo para circuitos integrados y componentes discretos para soportar opciones adicionales de I/O tales como expansin paralela, y otros puertos seriales y CAN.

2.2 LA TARJETA CPU08

La tarjeta CPU08 es un sistema embebido desarrollado en la Universidad del Valle basado en el microcontrolador AT89C52 de Atmel. Segn el diagrama de la

Figura 1.1, en esta tarjeta se debe implementar algunas funciones MODBUS apropiadas para comportarse como un esclavo, y adems debe manejar una red RS-485 de controladores a travs de un protocolo codificado en ASCII.

42

2.2.1 Diagrama de bloques.

El diagrama de bloques para la tarjeta CPU08 es presentado en la Figura 2.5.

Figura 2.5 Diagrama de bloques de la CPU08

2.2.2 Caractersticas.

!" 8k bytes de memoria de programa interna. !" 256 bytes de memoria RAM interna. !" 8k bytes de memoria RAM externa. !" 3 contadores / temporizadores de 16 bits. !" 4 entradas digitales aisladas (a travs de optoacopladores). !" Puerto serial RS-232 / RS-485.

43

!" Puerto sncrono SPI. !" 2 interrupciones externas. !" Voltaje de alimentacin regulado de +5V. !" Presenta conectores para expandir las funciones del sistema.

Adems, se proporciona un programa bootloader residente en la memoria flash que carga el programa de aplicacin en la RAM externa para propsitos de desarrollo y depuracin, de forma que la aplicacin pueda ser fcilmente modificada.

2.2.3 Programacin de la CPU08.

La tarjeta CPU08 se programa directamente en el lenguaje propio del microcontrolador AT89C52. Opcionalmente, es posible realizar la programacin en lenguaje C y utilizar un compilador cruzado que traslade el cdigo fuente C al lenguaje del microcontrolador. La utilizacin del lenguaje C para realizar la programacin depende de los requerimientos de desempeo y tamao de cdigo que se necesiten satisfacer.

En este proyecto, la programacin de la tarjeta CPU08 se realiz en lenguaje C usando el compilador proporcionado por el paquete Franklin, un entorno de desarrollo para aplicaciones basadas en microcontroladores de la familia 8051.

44

2.3 EL PLC DL05 DE KOYO

Este dispositivo PLC ofrece caractersticas convenientes para integrarlo en la red mostrada en la Figura 1.1, ya que proporciona un puerto serial que permite al PLC ser configurado como un maestro un esclavo MODBUS. En la figura el PLC se comporta como un dispositivo esclavo MODBUS.

2.3.1 Diagrama de bloques.

El diagrama de bloques para el dispositivo PLC Direct DL05 de Koyo es mostrado en la Figura 2.6.

Figura 2.6 Diagrama de bloques del PLC DL05

45

La funcin HSIO (High-Speed I/O) que proporciona este PLC, consiste de hardware dedicado pero configurable en el DL05. Para ms informacin sobre su operacin consultar el manual del PLC.

2.3.2 Caractersticas.

!" 8 entradas DC de alta velocidad. !" 6 salidas rel. !" Conjunto de 129 instrucciones para programacin. !" Memoria de programa de 2K bytes. !" Memoria de datos de 4K bytes. !" 2 puertos de comunicacin RS-232. !" Soporta los protocolos DeviceNet y MODBUS. !" Algoritmos PID integrados, con lazo auto-tunning. !" Mdulos opcionales de entrada / salida anlogos.

2.3.3 Modos de operacin.

El PLC DL05 posee tres modos de operacin: modo TERM, modo RUN y modo STOP. En la Tabla 2.1 se describen los tres modos de operacin del PLC.

46

Tabla 2.1 Modos de operacin del PLC DL05 Modo Descripcin (Terminal). Estn disponibles los modos de depuracin, programacin y ejecucin. Los diferentes modos y los TERM cambios en la programacin pueden ser conmutados a travs del software de programacin. (Ejecucin del Programa). La CPU es forzada dentro RUN del modo de ejecucin si no existen errores. STOP La CPU es forzada a parar.

2.3.4 Mapa de memoria.

Los tipos de memoria del PLC se dividen en dos categoras :

!" Discretos: X, SP, Y, CR, S, T, C.

!" Palabras de memoria: valor actual del timer, valor actual del contador, datos de usuario.

La Tabla 2.2 muestra los distintos tipos de memoria del PLC DL05, con sus respectivas direcciones en octal y su correspondiente valor en decimal para ser procesadas por una aplicacin MODBUS.

47

Tabla 2.2 Tipos de memoria del PLC DL05 Tipo de memoria del PLC
Datos discretos Entradas (X) Rels especiales Salidas (Y) 256 512 256 X0 X377 SP0 SP777 Y0 Y377 C0 C777 T0 T177 CT0 CT177 S0 S377 2048 - 2303 3072 3583 2048 2303 3072 3583 6144 6271 6400 6527 5120 5375 Entrada Entrada Salida Salida Salida Salida Salida

Cantidad (decimal)

Rango PLC (octal)

Rango en Modbus (decimal)

Tipo de dato Modbus

Rels de control (CR) 512 Timers (T) Contadores (CT) Bits de status Palabras de memoria Valor actual del timer 128 (V) Valor actual del 128 128 128 256

V0 V177

0 127

Registro entrada

de

V1000 V1177

512 - 639

Registro entrada

de

contador (V) Memoria V, dato de 3168 usuario (V) Memoria V, no voltil 128 (V) V7600 V7777 3968 - 4095 V1200 V7377 640 3809

Registro retencin Registro retencin

de

de

2.3.5 Comunicacin.

El PLC DL05 posee dos puertos de comunicacin RS-232. Las caractersticas de los puertos 1 y 2 se muestran en las Tablas 2.3 y 2.4 respectivamente.

48

Tabla 2.3 Caractersticas del puerto 1 del PLC DL05 Paquete de programacin Rata de baudios Bits de inicio Bits de datos Paridad Bits de parada Comunicacin Protocolos soportados Direccin del dispositivo DirectSOFT. 9600 bps (fijos). 1 8 Impar (por defecto), par, ninguna 1 Asncrona, half duplex con el DTE. K-sequence, DirectNET y MODBUS RTU, todos como esclavos. 1 (fija)

Tabla 2.4 Caractersticas del puerto 2 del PLC DL05 Paquete de programacin Rata de baudios Bits de inicio Bits de datos Paridad Bits de parada Comunicacin Protocolos soportados Direccin del dispositivo DirectSOFT. 300, 600, 1200, 2400, 4800, 9600, 19200 y 38400. 1 8 Impar (por defecto), par, ninguna. 1 Asncrona, half duplex con el DTE. K-sequence, DirectNET, MODBUS RTU (maestro o esclavo) y Non-sequence (para impresin). 1 a 247.

49

2.3.6 Programacin.

El PLC DL05 posee dos mtodos de programacin: RLL (Relay Ladder Logic) y RLL PLUS (PLUS PROGRAMMING). El PLC puede ser programado con un paquete de programacin avanzado, DirectSOFT, un software basado en Windows que soporta las caractersticas ms familiares para este sistema operativo.

2.4 CONTROLADORES 452 PLUS

Los controladores 452 Plus son dispositivos que permiten realizar lectura de variables, manejo de setpoint, establecer estrategias de control, tal como algoritmos PID, para llevar a cabo automatizacin de procesos. La configuracin de los parmetros del controlador (setpoint, cte. Proporcional, cte. Derivativa, etc.) pueden ser establecidos localmente a travs del panel frontal, remotamente a travs de una interfaz serial RS-232, RS-423A, RS-422A, RS-485.

La comunicacin remota con el controlador se desarrolla serialmente usando un protocolo asncrono codificado en ASCII de 7 bits con paridad par, un bit de parada y un bit de inicio, a 9600, 4800, 1200 300 bps.

50

2.4.1 Definicin de caracteres especiales.

Los controladores 452 Plus establecen para la comunicacin un conjunto de caracteres especiales ASCII no imprimibles, mostrado en la Tabla 2.5.

Tabla 2.5 Caracteres especiales ASCII del controlador Carcter especial < STX > < ETX> < EOT> < ACK > < LF > < CR > < NAK > < SYN > < ESC > < DEL > Cdigo hexadecimal 02 03 04 06 0A 0D 15 16 1B 7F Descripcin Caracter de inicio de trama. Caracter de fin de trama. Caracter de fin de transmisin. Caracter de reconocimiento. Caracter de nueva lnea. Caracter de retorno. Caracter de no reconocimiento. Caracter de sincronizacin. Caracter de borrado de lnea. Caracter de borrado de carcter.

2.4.2 Protocolo de Comunicacin.

El protocolo de comunicacin est definido en dos capas niveles; la primera define el wrapping del mensaje (la delimitacin de su inicio y su fin), mientras la segunda describe el contenido del mensaje.

51

2.4.2.1 Nivel 1 El Wrapping.

Este depende de la complejidad de la comunicacin que se desea establecer. Dos modos de comunicacin son ofrecidos: el modo VDU (Visual Display Unit) y el modo CRL (Control).

El modo VDU est definido para comunicacin simple entre un terminal y un controlador. Aqu un mensaje no necesita caracteres de inicio, y es terminado con un caracter de retorno <CR>.

Con el modo CRL se define una comunicacin entre un computador y mltiples controladores. Este modo es ms complejo, ya que primero se debe especificar cual controlador se desea direccionar. La direccin es precedida por un caracter especial <SYN> que indica al dispositivo receptor que el prximo caracter es interpretado como la direccin.

En modo CRL los mensajes individuales estn delimitados por <STX> para indicar el inicio y <ETX> para indicar el final.

2.4.2.2 Nivel 2 Contenido del mensaje.

Existen seis tipos de mensajes: establecer una variable anloga, establecer una variable lgica, leer un valor anlogo, leer un valor lgico, al igual que lectura de un bloque de valores anlogos lgicos.

52

Tabla 2.6 Tipos de mensaje del controlador 452 Plus Tipo de mensaje RA RL SA SL DA DL Leer variable anloga. Leer variable lgica. Escribir en localizacin anloga. Escribir en localizacin lgica. Leer 10 posiciones anlogas desde la posicin de inicio. Leer 10 posiciones lgicas desde la posicin de inicio. Descripcin

2.4.3 Contenido de posiciones anlogas del controlador 452 Plus.

En la Tabla 2.7 se relacionan algunas de las posiciones anlogas propias de los controladores 452 Plus.

Tabla 2.7 Posiciones de memoria del controlador 452 Plus Posicin anloga 0 1 2 3 7 8 9 Descripcin Tipo de instrumento (slo lectura). Valor medido (slo lectura). Setpoint. Potencia de salida (0 100 %). Banda proporcional (%)(0 - 500.0). Trmino integral (minutos)(0 200.0). Trmino derivativo (segundos)(0 4000).

53

3. DESCRIPCIN DEL SOFTWARE

Sobre los elementos que componen la red Modbus/TCP (Figura 1.1) se ejecutan diversos programas que son los que proporcionan la funcionalidad al sistema. El desarrollo del software se dividi en las siguientes etapas:

1. Desarrollo de un servidor Modbus/TCP en la tarjeta TINI. 2. Desarrollo de un servidor Web en la tarjeta TINI. 3. Desarrollo de una interfaz grfica para acceso va Web. 4. Implementacin de un esclavo MODBUS en la tarjeta CPU08. 5. Programacin de la tarjeta CPU08 como maestro de una red RS-485 de controladores. 6. Configuracin del PLC DL05 como un esclavo MODBUS. 7. Configuracin de los controladores 452 Plus.

En las siguientes secciones se describe detalladamente cada uno de los componentes software y la interaccin que existe entre los mismos; adems se presenta cdigo fuente para determinados programas.

54

3.1 DESARROLLO DE UN SERVIDOR MODBUS/TCP

El protocolo Modbus/TCP est basado en el paradigma cliente / servidor: el proceso servidor acepta una peticin desde la red, ejecuta una accin basado en la peticin y devuelve el resultado al solicitante; un programa se convierte en cliente cuando enva una peticin al servidor y espera una respuesta. Este modelo es ilustrado en la Figura 3.1.

Figura 3.1 Modelo cliente / servidor

El programa servidor para Modbus/TCP reside en la tarjeta TINI y por tanto se desarroll en Java, basndose en las indicaciones establecidas en la gua de implementacin descrita en la seccin 1.7.1.

La implementacin del servidor hace uso de la programacin orientada a objetos y el multithread para aceptar solicitudes concurrentes. La estructura de clases y parte de la implementacin est basada en el proyecto jmodbus.24

24

Disponible en Internet en http://jmodbus.sourceforge.net

55

El objetivo del proyecto jmodbus es proveer libreras Java para permitir a dispositivos basados en este lenguaje comunicarse como maestros esclavos a travs de ModbusRTU, ModbusASCII ModbusTCP. El cdigo es abierto y est diseado para correr sobre dispositivos con poca memoria, tales como la TINI de Dallas Semiconductor.

3.1.1 Estructura de Clases.

Un diagrama de la estructura de clases est en la Figura 3.2, donde se observa la clase base Modbus al igual que las implementaciones maestro y esclavo, y como stas se relacionan con implementaciones especficas de transporte.

Figura 3.2 Estructura de clases

56

En la Figura 3.3 se ilustra la estructura de ModbusTransport, la cual es una interface que es implementada por las clases que definen los diferentes mecanismos de transporte para la familia MODBUS (RTU, ASCII y TCP).

Figura 3.3 Estructura de la interface de transporte

3.1.2 Descripcin de las Clases.

La aplicacin desarrollada que corre en la TINI se encuentra conformada por las siguientes clases:

!" Clase Modbus. Clase para representar un dispositivo MODBUS. Esta es la clase base que ser extendida por las clases representando tanto un maestro como un esclavo MODBUS.

57

!" Clase ModbusMaster. Clase para representar un dispositivo maestro MODBUS. Esta es la clase base que ser extendida por las clases representando un maestro para los diferentes transportes (RTU, ASCII y TCP). Esta clase contiene el cdigo requerido para generar una solicitud MODBUS y analizar la respuesta.

!" Clase ModbusRTUMaster. Clase para implementar un dispositivo maestro MODBUS RTU. Esta clase define qu tipo de transporte es usado; todo el trabajo en generar y enviar solicitudes es desempeado por los mtodos en la clase ModbusMaster.

!" Clase ModbusRTUTransport. Clase para implementar un mecanismo de transporte RTU para comunicacin MODBUS. Esta clase permite a un dispositivo comunicarse serialmente, usando codificacin RTU para los datos.

!" Clase ModbusSlave. Clase para representar un dispositivo esclavo MODBUS. Esta es la clase base que ser extendida por las clases representando un esclavo para los diferentes transportes (RTU, ASCII, y TCP). Esta clase contiene el cdigo que es requerido para la recepcin y el procesamiento de solicitudes. Esta clase tambin implementa la interfaz Runnable25, as que cualquier instancia de esta clase puede correr como un thread independiente.

25

La interfaz Runnable permite manejar multihilos sin necesidad de extender la clase Thread.

58

!" Clase ModbusTCPSlave. Clase para implementar un dispositivo esclavo Modbus/TCP. Esta clase corre como un thread independiente. La clase solo define que tipo de transporte es usado; el trabajo en la recepcin y el procesamiento de solicitudes es desempeado por los mtodos de la clase ModbusSlave.

!" Clase ModbusTCPTransport. Clase para implementar un mecanismo de transporte TCP para la comunicacin MODBUS. Esta clase permite a cualquier dispositivo comunicarse va Modbus/TCP. Esta clase debe implementar los mtodos definidos en la interface ModbusTransport.

!" Clase ModbusMessage. Clase para representar un mensaje MODBUS. Esta clase encapsula todos los elementos de un mensaje que son considerados comunes a todas las implementaciones de MODBUS.

!" Clase ServidorModbusTCP. Esta es la aplicacin principal que se mantiene esperando por solicitudes de conexin al puerto 502 de TCP, el puerto registrado de Modbus/TCP, y cuando arriva una peticin crea un nuevo hilo que procesa la transaccin, mientras la aplicacin contina escuchando por nuevas solicitudes.

59

!" Interface ModbusTransport. Interface para los mecanismos de transporte MODBUS. Esta interface es implementada por las clases que representan el transporte para los diferentes tipos de MODBUS. Las clases que implementan esta interface son responsables por el enmarcado, delimitacin y codificacin de tramas MODBUS desde el medio de transporte y el envo y recepcin real de los datos.

La aplicacin desarrollada se comporta como un servidor ( esclavo) Modbus/TCP, pero tambin acta como un gateway de forma que es capaz de direccionar solicitudes MODBUS destinados a otros esclavos a travs de MODBUS RTU.

3.1.3 Ejemplo de cdigo fuente.

En esta seccin se describen algunos apartes importantes del cdigo fuente de la aplicacin que ejecuta la tarjeta TINI.

Java ofrece comunicaciones basadas en sockets que permite las aplicaciones manejar el trabajo en redes como si fuera entrada / salida de archivos; por tanto el servidor que corre en la TINI est fundamentado en este concepto. En la Figura 3.3 se lista una porcin del cdigo de la clase ServidorModbusTCP, la cual fue explicada en la seccin anterior.

60

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

import java.net.* ; public class ServidorModbusTCP { private final int DIRECCION = 1; private final int PUERTO = 502; private final int NUMERO_DE_CONEXIONES = 2; . . . public static void main (String args[ ]) { ServerSocket svrSocket = null; Socket socket = null; Thread hiloModbus; ModbusTCPSlave modbus; . . . try { svrSocket = new serverSocket( PUERTO ); } catch( IOException ex ) { System.out.println( ex.getMessage( ) ); ex.printStackTrace( ); return; } while( true ) { try { socket = svrSocket.accept( ); modbus = new ModbusTCPSlave( DIRECCION, socket ); hiloModbus = new Thread ( modbus ); hiloModbus.start( ); } catch ( IOException ex ) { System.out.println( ex.getMessage( ) ); ex.printStackTrace( ); } } } }

Figura 3.3 Programa en Java de un servidor Modbus/TCP

61

La creacin de una conexin socket TCP/IP se realiza directamente con el paquete java.net. De ah que con el enunciado de la lnea 1 se cargan las clases del paquete de trabajo con redes de Java (Java Networking Package).

Las lneas 5, 6 y 7 definen constantes requeridas en la clase ServidorModbusTCP como el nmero de puerto y el identificador de unidad.

Para establecer un servidor en Java, se utilizan instancias de las clases ServerSocket y Socket.

En la lnea 13 se declara un objeto de la clase ServerSocket. Este es el objeto utilizado en la aplicacin servidor para escuchar las peticiones que realicen los clientes. Este objeto no realiza el servicio, sino que crea un objeto Socket en funcin del cliente para realizar toda la comunicacin a travs de l.

En la lnea 14 se declara un objeto de la clase Socket. Este es el objeto bsico en toda comunicacin a travs de Internet, bajo el protocolo TCP. Esta clase proporciona mtodos para la entrada/salida a travs de streams.

En la lnea 15 se declara un objeto de la clase Thread. Esta es la clase que Java proporciona para dar soporte al multihilado y a las capacidades de la programacin concurrente.

62

Una instancia de la clase ModbusTCPSlave se declara en la lnea 16. Esta clase fue explicada anteriormente y se ejecuta como un nuevo hilo por cada solicitud de conexin que recibe el servidor. Por tanto esta clase debe implementar el mtodo run (ejecutar) de la clase Thread. El cdigo que realiza el verdadero trabajo de un hilo se coloca en su mtodo run.

Con el enunciado de la lnea 20 se establece al objeto ServerSocket el puerto en el que el servidor esperar las conexiones de los clientes. El argumento NUMERO_DE_CONEXIONES especifica el nmero de clientes que pueden esperar una conexin y ser procesados por el servidor. Si la cola est llena, las conexiones de los clientes se rechazarn automticamente.

En la lnea 29 se establece un ciclo while, el cual contiene el bloque de cdigo que el servidor permanecer ejecutando siempre, que consiste bsicamente en esperar por solicitudes de conexin y la creacin de hilos concurrentes para cada conexin.

Una vez establecido el ServerSocket, el servidor escucha indefinidamente ( se bloquea) para detectar un intento de un cliente por conectarse. Esto se logra con la llamada de mtodo accept( ) de la clase ServerSocket, la cual devuelve un objeto Socket cuando se establece una conexin. En la lnea 32 se ejecuta esta accin.

63

En la lnea 34 se crea un hilo para manejar la conexin, y el programa inicia la ejecucin del hilo invocando el mtodo start (arrancar) de ese hilo (lnea 35); a su vez, start invoca el mtodo run. Una vez que start echa a andar el hilo, regresa de inmediato al invocador. De ah en adelante, el invocador ( el servidor ) se ejecutar en paralelo con el hilo iniciado.

3.2 DESARROLLO DE UN SERVIDOR WEB

El protocolo HTTP (HyperText Transfer Protocol, protocolo de transferencia de hipertexto) que constituye la base de la World Wide Web, est basado en el modelo cliente / servidor y posee el puerto registrado 80 de TCP.

El servidor Web que corre en la tarjeta TINI se desarroll en Java y la aplicacin bsicamente implementa la funcin GET que se define en la especificacin del protocolo HTTP.

El servidor permite manejar mltiples conexiones concurrentemente; el programa se mantiene escuchando en el puerto de HTTP y cuando llega una peticin GET, se crea un proceso hijo que maneja esa transaccin particular y ste devuelve una pgina HTML (HyperText Markup Language) al cliente.

En la Figura 3.4 se lista parte del cdigo que define al servidor Web.

64

1 import com.dalsemi.tininet.http.HTTPServer; 2 import com.dalsemi.tininet.http.HTTPServerException; 3 4 class WebServer { 5 public static void main(String[] args) { 6 7 // Construir una instancia of HTTPServer que escuche al puerto 80 8 HTTPServer httpd = new HTTPServer(80); 9 10 // Establecer el nombre del directorio donde reside la pgina Web y 11 // el nombre del archivo html principal. 12 httpd.setHTTPRoot("/html"); 13 httpd.setIndexPage("Index.html"); 14 15 // Especificar un nombre para el archivo de logging y habilitarlo 16 httpd.setLogFilename("/log/web.log"); 17 httpd.setLogging(true); 18 19 // Procesar las solicitudes ingresantes 20 for ( ; ; ) { 21 try { 22 httpd.serviceRequests(); 23 } 24 catch (HTTPServerException e) { 25 System.out.println(e.getMessage()); 26 } 27 } 28 29 } 27 } Figura 3.4 Ejemplo de cdigo para un servidor Web

La pgina HTML devuelta por el servidor Web al cliente contiene una applet, la cual es la que verdaderamente representa la interfaz grfica de usuario que permite acceso remoto desde Internet. El desarrollo de esta applet se presenta en la seccin 3.3.

65

Las applets son un tipo de aplicaciones que Java permite crear, que se mantienen ( residen) en el servidor Web, son transportadas a travs de Internet, instaladas automticamente en la mquina cliente y que se ejecutan localmente como parte de una pgina Web.

En la Figura 3.5 se lista el contenido del archivo HTML que define la pgina Web, y que tiene embebida a la applet. 1 <HTML> 2 <HEAD> 3 <TITLE> RED MODBUS/TCP</TITLE> 4 </HEAD> 5 <BODY BGCOLOR=FFFFFF> 6 <CENTER> 7 < APPLET ARCHIVE = Programa.jar CODE = "Programa.class 8 WIDTH = 750 HEIGHT = 420 VSPACE = 80> 9 </APPLET> 10 </CENTER> 11 </BODY> 12 </HTML> Figura 3.5 Archivo HTML que carga la applet en un navegador Web

Para mejorar el desempeo, en el archivo HTML se hace uso de una herramienta del JDK: el programa JAR para la creacin de archivos de tipo JAR (Java Archive). Los beneficios que se obtienen con este programa tiene que ver con el tiempo de respuesta en la carga de la applet. Cuando se ejecuta una applet, el browser o navegador hace tantas conexiones al servidor como clases componen la applet. Si por el contrario se crea un archivo JAR que contenga todas las clases que son cargadas por la applet, el navegador solo realizar una conexin adicional al servidor. Esto har que la applet se cargue ms rpidamente.

66

3.3 DESARROLLO DE UNA INTERFAZ PARA ACCESO WEB

En esta seccin se describe la herramienta con la cual un usuario puede remotamente leer y escribir registros posiciones discretas sobre los diversos elementos que componen la red Modbus/TCP implementada (Figura 1.1), a travs de una red TCP/IP como por ejemplo Internet.

La herramienta se ha desarrollado como una applet de Java de forma que un usuario puede acceder la red Modbus/TCP desde cualquier parte en Internet, utilizando solamente un browser navegador independientemente de la plataforma en que se encuentre el usuario.

El applet desarrollado posee las siguientes caractersticas:

!" Control de acceso de usuarios; slo personas autorizadas pueden acceder la red Modbus/TCP. !" Monitoreo de variables ( valor medido, entradas discretas, etc. ) . !" Control de variables ( setpoint, salidas discretas, etc. ). !" Todas las operaciones de supervisin y control de variables se realizan utilizando el protocolo Modbus/TCP, por tanto la applet debe codificar las solicitudes segn este estndar.

67

3.3.1 El applet como un cliente Modbus/TCP.

Adems de proveer la interfaz grfica para interaccin con el usuario, el applet tambin debe comunicarse con un servidor Modbus/TCP. Por tanto, como parte integral del applet se ha implementado un cliente Modbus/TCP, segn las indicaciones establecidas en la seccin 1.7.2.

En Java para establecer la comunicacin como cliente se utiliza un objeto de tipo Socket para conectarse con el servidor, un objeto InputStream para recibir informacin del servidor y un objeto OutputStream para enviar informacin al servidor.

InputStream (una subclase de Object) y OutputStream (una subclase de Object) son clases abstractas que definen mtodos para realizar operaciones de entrada y salida respectivamente.

El cdigo en Java que se ilustra en la Figura 3.6 establece comunicacin con un servidor Modbus/TCP remoto, construye una solicitud segn el protocolo, enva la solicitud y la respuesta recibida del servidor es verificada. La solicitud Modbus/TCP que se implementa en el cdigo de la figura es Leer mltiples registros.

68

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

import java.io.* ; import java.net.* ; class ClienteModbusTCP { private final int PUERTO = 502 ; private Socket socket = null; private OutputStream output = null; private BufferedInputStream input = null; private int buffer[ ] = new int [261]; // Rutina para funcin de MODBUS. Cdigo de funcin 03. void Leer_Multiples_Registros ( String dns, // Direccin IP del servidor int unidad, // Identificador de unidad int referencia, // Nmero de referencia (posicin) int cantidad, // Cantidad de registros a leer int registros[ ] ) // Buffer para colocar los valores ledos { int c, i; try { // Crear el socket y establecer las conexiones de flujo respectivas socket = new Socket ( dns, PUERTO ); output = socket.getOutputStream( ); input = new BufferedInputStream( socket.getInputStream( ) ); // Construir la trama Modbus/TCP leer registros for ( i=0; i<5; i++ ) buffer[ i ] = 0; buffer[ 6 ] = (byte) unidad; buffer[ 7 ] = 3; buffer[ 8 ] = (byte) (referencia >> 8); buffer[ 9 ] = (byte) (referencia & 0xFF); buffer[ 10 ] = 0; buffer[ 11 ] = (byte) cantidad; buffer[ 5 ] = 6; // Enviar la solicitud al servidor output.write( buffer, 0, 12 ); // Esperar y leer la respuesta c = input.read( buffer, 0, 261 );

69

46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73

// Verificar la respuesta y extraer los valores ledos if ( c == ( 9+2*cantidad ) && buffer[ 7 ] == 3 ) { for ( i = 0; i<cantidad; i++ ) { // Construir el valor de registro de los bytes alto y bajo registros[ i ] = ( ( (int) buffer[ 9+2*i ] ) << 8 ) & 0xFF00 | ( (int) buffer[ 10+2*I ] & 0xFF ); } } else System.out.println ( Respuesta recibida erronea \n ); // Cerrar la conexin socket socket.close( ); } catch (Exception e) { System.out.println ( e.getMessage( ) ); e.printStackTrace( ); return; } return; } } Figura 3.6 Cdigo en Java para un cliente Modbus/TCP

En el programa anterior se define una funcin, Leer_Multiples_Registros, la cual recibe diversos parmetros que se requieren para construir y enviar la solicitud. A continuacin se describen algunos aspectos relevantes del cdigo.

!" Es necesario importar el paquete java.io en el programa para realizar operaciones de entrada / salida con sockets en Java. Este paquete incluye las definiciones de las clases de flujos, como Outputstream y BufferedInputStream.

70

!" Con un objeto BufferedInputStream ( una subclase de FilterInputstream ), muchos segmentos lgicos de datos se leen en una sola operacin de entrada fsica y se colocan en un buffer de la memoria. As, el nmero de operaciones de entrada fsica reales es pequeo en comparacin con el nmero de solicitudes de lectura emitidas por el programa, mejorando el rendimiento del sistema.

!" Los mtodos getInputStream y getOutputStream sirven para obtener referencias a los InputStream y OutputStream respectivamente, asociados al Socket.

3.3.2 Sistema de acceso.

El applet desarrollado proporciona una interfaz visual independiente de la plataforma, la cual puede ser ejecutada por cualquier navegador en Internet. Existe un sistema de acceso para restringir a personas no autorizadas realizar operaciones sobre la red Modbus/TCP (Figura 1.1).

El sistema de acceso est implementado con la utilizacin de un nombre de usuario ( login ) y una palabra clave ( password ), los cuales debe poseer una persona para obtener el panel de control desde el cual acceder a la red Modbus/TCP.

71

En la Figura 3.7 se observa la ventana que se obtiene cuando desde Internet se ingresa la direccin del servidor Web que se encuentra en la tarjeta TINI.

Figura 3.7 Interfaz del Sistema de Acceso

Solamente si se proporciona el login y el password correctos, la ventana desaparece y se visualiza el panel de control.

La ventana del sistema de acceso est implementada utilizando la librera AWT (Abstract Window Toolkit) de Java, que es un kit completo con herramientas para manejo de grficos como paneles, ventanas, botones, mens, etc.

3.3.3 Panel de Control.

El panel de control hace parte del applet desarrollado; es la ventana que provee elementos como botones, campos de texto, componentes grficos, etc., la cual visualiza el contenido o el estado de los diferentes registros y datos discretos que poseen los esclavos que conforman la red Modbus/TCP. Adems, desde el panel es posible cambiar el contenido de determinados registros y valores discretos.

72

En la Figura 3.8 puede observarse el aspecto del panel de control que se cargara en un navegador Web.

Figura 3.8 Vista del panel de control

La informacin que se despliega en el panel de control se actualiza constantemente; esto se realiza a travs de un thread independiente que se comunica con los elementos remotos de la red, envindoles solicitudes Modbus/TCP de lectura. Sin embargo, la informacin que se visualiza no es en tiempo real debido a los retardos a travs de la red.

73

3.4 IMPLEMENTACION DE UN ESCLAVO MODBUS EN LA CPU08

Como se expuso en la seccin 2.2.5, la tarjeta CPU08 puede ser programada en lenguaje C; la implementacin del esclavo MODBUS se desarroll en este lenguaje y utilizando el paquete Franklin. El programa residente en la CPU08 es capaz de procesar las funciones del protocolo MODBUS escribir mltiples registros (cdigo 16 hexadecimal) y leer mltiples registros (cdigo 03 hexadecimal).

Para la aplicacin a la que est destinada la tarjeta CPU08, solo se requieren estas dos funciones ya que el programa bsicamente redirecciona la solicitud (de lectura escritura) a una subred RS-485 de controladores, los cuales entienden determinados tipos de mensaje que son similares a las funciones MODBUS previamente mencionadas; la CPU08 acta como interfaz entre el protocolo MODBUS y el protocolo codificado en ASCII de los controladores 452 Plus.

El programa de la CPU08 efecta la conversin de protocolos de forma que la solicitud MODBUS de lectura de registros se asocia con el tipo de mensaje RA (leer variable anloga) del controlador 452 Plus; as mismo, la solicitud MODBUS de escritura de registros se asocia con el tipo de mensaje SA (escribir en localizacin anloga) del controlador 452 Plus. Para una descripcin de los tipos de mensajes del controlador revisar la tabla 2.6 y la seccin 3.5.

74

De acuerdo a la seccin 2.2.2, la tarjeta CPU08 posee un solo puerto de comunicaciones RS-232 RS-485. La aplicacin que se desarroll para la CPU08 requiere de la existencia de dos puertos de comunicacin serial, por tanto uno de los cuales se implement por software utilizando dos pines de propsito general, que simulan las seales Rx y Tx de una UART.

El puerto de comunicaciones RS-485 que tiene la tarjeta se utiliza para establecer la comunicacin con los controladores 452 Plus. La UART del microcontrolador AT89C52 de la CPU08 est configurada en modo 2, donde se transmiten 8 bits: 7 bits de datos (caracteres ASCII) y un bit de paridad par, a una rata de 9600 bps y con un solo bit de parada.

Los datos intercambiados entre la CPU08 y los controladores 452 Plus son de tipo decimal, por tanto en la CPU08 se debe codificar la informacin segn el estndar IEEE754 que define el formato para el almacenamiento y la transmisin de datos flotantes. Cada dato flotante se debe tratar como dos registros holding segn el protocolo MODBUS.

3.4.1 Algoritmo de la aplicacin para la CPU08.

El algoritmo para el programa residente en la tarjeta CPU08 puede ser apreciado en la Figura 3.9.

75

Figura 3.9 Algoritmo para el programa de la CPU08

76

Una descripcin detallada de las diferentes etapas que componen el algoritmo es presentada a continuacin.

!" Inicio. Se establecen los valores para los registros de funcin especial del microcontrolador de la tarjeta CPU08.

!" Etapa 1. Esperar a travs de la UART implementada por software, una solicitud MODBUS a ser procesada.

!" Etapa2. verificar la integridad de la trama MODBUS recibida. Bsicamente corroborar el cdigo de chequeo de error (CRC) recibido con el calculado. Adems comprobar que el mensaje es direccionado a la tarjeta.

!" Etapa 3. realizar una discriminacin basndose en el campo de cdigo de funcin, para enviar el mensaje a la rutina respectiva.

!" Etapa 4. Generar una respuesta de excepcin indicando que el cdigo de funcin recibido no es soportado por el esclavo MODBUS.

!" Etapa 5. Rutina para procesar la funcin de leer mltiples registros. Se encuentra conformada por las etapas 7, 10 y 12.

77

!" Etapa 6. Rutina para procesar la funcin de escribir mltiples registros. Se encuentra conformada por la etapas 8, 11 y 13.

!" Etapa 7 y 8. Verificar que la solicitud MODBUS se encuentra correcta. Por ejemplo comprobar que el registro que se pretende leer escribir se encuentra dentro del rango de direcciones manejado por el esclavo MODBUS.

!" Etapa 9. Generar una respuesta de excepcin, indicando el tipo de excepcin que se produjo.

!" Etapa 10 y 11. Construir y enviar una solicitud de lectura escritura segn el caso al controlador respectivo, teniendo en cuenta el protocolo de comunicacin ASCII que manejan esos dispositivos. Esto se realiza a travs del puerto serial RS-485 de la CPU08.

!" Etapas 12 y 13. A travs del puerto RS-485 de la CPU08, recibir y verificar la respuesta del controlador a la solicitud de lectura o escritura. A partir de los datos obtenidos, armar segn el protocolo una respuesta MODBUS a la solicitud procesada.

!" Etapa 14. Enviar la respuesta a la trama MODBUS recibida, a travs de la UART implementada por software.

78

La aplicacin embebida residente en la tarjeta CPU08 se mantiene cclicamente esperando por tramas MODBUS y procesando las solicitudes.

En la seccin 3.5 se describe detalladamente la codificacin de una trama de solicitud respuesta para los controladores 452 Plus, segn el protocolo de comunicacin de estos dispositivos.

La Tabla 3.1 describe los pines de los puertos utilizados por el microcontrolador que posee la tarjeta CPU08, al igual que la funcin que desempean.

Tabla 3.1 Pines utilizados por la tarjeta CPU08 Puerto P3.5 P1.3 P1.6 P3.0 P3.1 P3.3 Descripcin Simula la seal de recepcin de una UART. Simula la seal de transmisin de una UART. Seal de habilitacin para el driver RS-485. Pin de recepcin de la UART del microcontrolador. Pin de transmisin de la UART del microcontrolador. Interrupcin externa que activa la recepcin en la UART implementada.

Tambin son utilizados los dos pines provenientes del driver RS-485 de la CPU08, que proporcionan las seales A y B del canal diferencial de transmisin y recepcin.

79

3.4.2 La UART implementada por software.

Los pines 3 y 5 del puerto 3 junto con el pin 3 del puerto 1 proporcionan la funcionalidad de una UART adicional para la tarjeta CPU08, como fue requerido para la aplicacin propuesta.

Se hace uso de una interrupcin externa para indicarle a la rutina de recepcin la llegada de un byte, y para iniciar el temporizador que genera la seal de reloj. Cuando arriva el bit de inicio de un byte (nivel lgico 0) se genera la interrupcin externa 1, activa por flanco descendente, instante en el que se sincroniza el temporizador TR0 el cual permanecer activo hasta que termine la llegada de la trama completa o se genere un timeout.

Segn el protocolo MODBUS RTU, la separacin mxima entre bytes dentro de una misma trama de lectura o escritura es de 3.5 veces el perodo de reloj; en la rutina de recepcin se desarrolla esta verificacin del tiempo de separacin. En la rutina de recepcin tambin se realiza la verificacin de los bits de inicio y de parada para cada byte que llega.

La seal de reloj se establece al doble de la rata de baudios a la cual se realiza la comunicacin, para garantizar que cada uno de los bits son ledos en la mitad del slot de tiempo y no cerca de los lmites del slot donde podra generarse inexactitudes en la lectura. Esto es bosquejado en el diagrama de la Figura 3.10.

80

Figura 3.10 Lectura de bits en la UART implementada

3.5 LA CPU08 COMO MAESTRO DE UNA RED DE CONTROLADORES

La tarjeta CPU08 debe programarse para que se comporte como maestro de una red RS-485 de controladores 452 Plus, utilizando el protocolo de comunicacin codificado en ASCII que entienden esos dispositivos. Referirse a la seccin 2.4.2 para una descripcin detallada de dicho protocolo.

Para la aplicacin a la que est destinada la CPU08, existen dos tipos de mensajes distintos para comunicarse con los controladores 452 Plus, que se presentan a continuacin.

81

!" Mensaje para leer una variable anloga: <SYN>Direccin_del_controlador<STX>RA Direccin_de_la_variable<ETX>

!" Mensaje para escribir en una variable anloga: <SYN>Direccin_del_controlador<STX>SA Direccin_de_la_variable Dato<ETX>

3.5.1 Respuestas del controlador 452 Plus a solicitudes.

Los controladores 452 Plus responden a todas las tramas correctamente definidas que reciben con un mensaje respuesta que consiste de una rplica exacta de la solicitud seguida por ya sea el caracter <ACK> el caracter <NAK>; cuando se da una respuesta de no reconocimiento <NAK>, la respuesta se acompaa con un caracter de error. Los posibles caracteres de error se detallan en la tabla 3.2.

Tabla 3.2 Caracteres de error del controlador 452 Plus Caracter 1 3 Descripcin Mensaje invlido Posicin invlida Ejemplo* RX 10 SA -10

* Estos son formatos de mensaje los cuales el controlador responder con no reconocimiento y el respectivo caracter de error.

Las solicitudes para establecer un valor en una posicin de solo lectura son ignorados silenciosamente.

82

Los mensajes de solicitud emitidos por la tarjeta CPU08 son respondidos por el controlador 452 Plus de la manera siguiente:

!" Respuesta a una solicitud de lectura: <STX>RA Direccin_de_la_variable<ACK>Dato<ETX><CR><LF>

!" Respuesta a una solicitud de escritura: <STX>SA Direccin_de_la_variable Dato<ACK><ETX><CR><LF>

Hay que tener en cuenta que un valor anlogo que se desee leer o escribir consiste de un nmero con un punto decimal opcional, como por ejemplo 12.34 3999; solamente 4 dgitos tienen significado para el controlador 452 Plus. Si el valor es negativo, el dato es precedido del caracter de signo negativo.

La tarjeta CPU08 enviar un mensaje de solicitud y entonces esperar por la respuesta. Sin embargo, es posible que el controlador 452 Plus no se encuentre encendido, o no reciba el mensaje por alguna razn. Por tanto en el programa de la CPU08 se establece un timeout cada vez que se enve una trama al controlador, para evitar que posiblemente se quede esperando eternamente. Si se completa en timeout, la CPU08 armar una respuesta de excepcin y la retornar al dispositivo maestro.

83

3.5.2 Ejemplos de mensajes de lectura y escritura.

A continuacin se presentan diversos ejemplos de solicitudes de lectura y escritura para los controladores 452 Plus, al igual que las tramas reales que sern enviadas a estos dispositivos.

!" Leer la constante proporcional del controlador 452 Plus que tiene direccin 1. En la Tabla 3.3 se observa la trama de solicitud.

Tabla 3.3 Ejemplo de trama de lectura del controlador 452 Plus Posicin del byte Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
paridad del protocolo (paridad par).

Caracter ASCII <SYN> 1 <STX> R A Espacio 7 <ETX>

Valor en hexadecimal* 96 B1 82 D2 41 A0 B7 03

* Este valor adems de representar al respectivo carcter ASCII, tambin coloca la

!" Establecer a 50 el setpoint del controlador 452 Plus que tiene la direccin 2. En la Tabla 3.4 se observa la trama de solicitud.

84

Tabla 3.4 Ejemplo de trama de escritura del controlador 452 Plus Posicin de byte Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8 Byte 9 Byte 10
paridad del protocolo (paridad par).

Caracter ASCII <SYN> 2 <STX> S A Espacio 2 Espacio 5 0 <ETX>

Valor en hexadecimal* 96 B2 82 53 41 A0 B2 A0 35 30 03

* Este valor adems de representar al respectivo carcter ASCII, tambin coloca la

3.6 CONFIGURACION DEL PLC DL05 COMO ESCLAVO MODBUS

Para realizar la configuracin del PLC DL05 como un esclavo MODBUS se han utilizado las caractersticas que se aprecian en la Tabla 3.5.

Tabla 3.5 Variables de configuracin del PLC DL05 Interfaz de comunicacin Puerto de comunicacin Direccin de esclavo Rata de baudios Bits de datos Paridad RS-232 Puerto 2 2 4800 8 ninguna

85

La comunicacin del PLC como dispositivo esclavo puede hacerse a travs de cualquiera de los dos puertos de comunicacin, sin embargo se opt por utilizar el puerto 2 porque es ms flexible en los parmetros que se le pueden establecer.

Segn la seccin 2.3.5, el PLC DL05 se programa con DirectSOFT. En la Figura 3.11 se observa la ventana para la configuracin del puerto 2, en DirectSOFT.

Figura 3.11 Configuracin del puerto 2 en DirectSOFT

La comunicacin con el PLC se establece con el protocolo MODBUS en modo RTU. Los cdigos de funcin MODBUS soportados por el PLC DL05, determinan si el acceso es de lectura escritura, y si el acceso es a un punto de datos simple a un grupo de ellos.

86

La Tabla 3.6 muestra las funciones MODBUS soportadas por el PLC DL05 al igual que los tipos de datos que maneja.

Tabla 3.6 Funciones MODBUS soportadas por el PLC DL05 Cdigo de funcin MODBUS 01 02 05 15 03 04 06 16 Funcin Leer un grupo de salidas discretas. Leer un grupo de entradas discretas. Cambiar un dato discreto simple. Cambiar un grupo de datos discretos. Leer mltiples registros. Leer mltiples registros de entrada. Escribir un valor en un registro simple. Escribir en un grupo de registros. Tipo de datos en el PLC DL05 Y, CR, T, CT X, SP Y, CR, T, CT Y, CR, T, CT V V V V

Para que puedan realizarse operaciones de escritura de registros de datos discretos sobre el PLC a travs del protocolo MODBUS RTU, el PLC debe encontrarse en modo de operacin TERM.

3.7 CONFIGURACION DE LOS CONTROLADORES 452 PLUS

Las variables de configuracin de los controladores 452 Plus requeridas para establecer la comunicacin serial a travs del puerto RS-485 son:

87

!" Rata de baudios. !" Direccin de comunicaciones. !" Modo de comunicacin ( modo CRL o VDU ). !" Nivel de proteccin de los datos.

Desde el panel frontal de los controladores 452 Plus se establecen los valores de las variables de configuracin, usando las funciones CS que se relacionan en la Tabla 3.7.

Tabla 3.7 Configuracin de los controladores 452 Plus Funcin CS_5 CS_6 CS_7** Valor 0, 1* 3 1 Descripcin Direccin del controlador ( 0 a 1F ) Rata de baudios ( 0-300, 1-1200, 2-4800, 3-9600 ) Modo CRL/VDU y nivel de proteccin ( 0-VDU, 1-CRL )

* Un solo valor para cada controlador. ** Para mayor informacin sobre los diversos valores que puede tomar esta funcin,
revisar el manual del controlador.

Para la comunicacin con los controladores 452 Plus se emplea el modo CRL (ver seccin 2.4), debido a que este modo facilita la comunicacin con ms de un controlador, lo cual resulta apropiado para la implementacin de la subred RS-485 dentro de la red Modbus/TCP.

88

3.7.1 Conexiones fsicas.

La interfaz serial RS-485 de los controladores 452 Plus se presenta fsicamente a travs de 4 pines que se detallan en la Tabla 3.8.

Tabla 3.8 Interfaz serial del controlador 452 Plus Nmero de pin 4 3 2 1 Seal Tx Tx + Rx + Rx -

Las seales Tx- y Tx+ conforman el canal diferencial de transmisin y las seales Rx- y Rx+ conforman el canal diferencial de recepcin.

Para realizar la conexin entre la tarjeta CPU08 y la subred RS-485 de controladores 452 Plus, se unen las seales Tx+ y Rx+ de cada uno de los controladores con la lnea A del driver RS-485 de la CPU08. Igualmente se unen las seales Rx- y Tx- de cada uno de los controladores con la lnea B del driver RS-485 de la CPU08.

89

4. CONCLUSIONES

!" Ante la incursin de la tecnologa Ethernet en el rea de los sistemas de control de procesos y la automatizacin, para la interconexin a nivel de campo de sensores, actuadores y controladores, han surgido diversos protocolos para comunicacin industrial sobre Ethernet. Sin embargo, una capa de aplicacin (segn el modelo de referencia OSI) estndar con un modelo de objetos comn, no existe. Modbus/TCP es un estndar de-facto y est ampliamente extendido y aceptado; Pero adems existen otros tres protocolos para el Ethernet industrial: EtherNet/IP (esencialmente objetos ControlNet y DeviceNet sobre TCP/IP y UDP), ProfiNet (combina el protocolo Profibus, OLE para control de procesos OPC y TCP/IP) y Fieldbus Foundation high-speed Ethernet HSE (coloca el protocolo H1 de Foundation Fieldbus sobre TCP/IP y aade OPC y el lenguaje XML).

!" En una red de control distribuido, el protocolo Modbus/TCP puede ser usado para comunicarse con una serie de controladores o PLCs distribuidos alrededor de la planta. Esto permite a una sola persona supervisar remotamente diversos procesos simultneamente desde una posicin nica.

90

Adems del monitoreo de variables (como la variable corriente del proceso), los parmetros operativos individuales (como el setpoint) de los controladores pueden ser cambiados para ajustar el proceso si es requerido.

!" La plataforma TINI result conveniente y apropiada para el sistema propuesto, ya que las aplicaciones desarrolladas en Java se ejecutaron eficientemente; adems, todo el proceso de programacin y depuracin de las aplicaciones se desarroll en un PC, para posteriormente transportar el cdigo a la tarjeta, agilizndose la creacin de los programas.

!" Con la implementacin del protocolo MODBUS y Modbus/TCP en la tarjeta CPU08 y la TINI respectivamente, se evidenci la facilidad y flexibilidad de este protocolo y por ende la razn de su alta difusin en entornos industriales. Adems, se demostr la interoperabilidad de la red implementada, de forma que desde clientes Modbus/TCP de diferentes fabricantes fue posible leer y escribir registros y datos discretos sobre los diversos elementos que conforman la red.

!" En la red implementada se integraron los protocolos Modbus/TCP, MODBUS y ASCII y los enlaces Ethernet, RS-232 y RS-485, demostrndose que sistemas de control de procesos ya instalados pueden ser supervisados y controlados desde una red TCP/IP (como Internet o la Intranet local) utilizando el estndar Modbus/TCP.

91

!" El monitoreo continuo de datos streaming data no es muy eficiente con el protocolo Modbus/TCP, debido bsicamente a la sobrecarga que impone el protocolo de transporte TCP. La sobrecarga tiene que ver con el servicio de entrega de datos confiable y el acuse de recibo para cada paquete transmitido, incrementndose considerablemente el trfico en la red cuando se monitorea en todo momento un esclavo Modbus/TCP particular. La solucin para la supervisin de datos continuo sobre una red Ethernet es la utilizacin del protocolo de transporte UDP.

!" Como una proyeccin futura del presente trabajo sera interesante poder integrarle a la tarjeta TINI el protocolo XML (eXtensible Markup Languaje), un lenguaje de gran crecimiento que ya abarca muchos campos en servicios de Web, y el cual ya incursion en el rea industrial para el intercambio de informacin. Con la tarjeta TINI, bsicamente este estndar se utilizara para que una base de datos con soporte XML (actualmente casi todas lo tienen) se comunique con ella y acceda continuamente a la informacin proveniente de los procesos. Esta informacin es almacenada en las tablas internas de la base de datos, y de esa forma es posible llevar registros, histricos, tendencias, grficos, reportes, etc. del comportamiento de las variables que se requieran. Actualmente, ya se encuentra en desarrollo un servidor de Web para la TINI con soporte XML, y en cdigo abierto.

92

!" La interfaz grfica de usuario para la supervisin y control de la red Modbus/TCP desde Internet que se desarroll como un applet de Java tambin es posible enfocarla desde un punto de vista diferente: El mecanismo de interaccin entre al usuario en la Web y la plataforma TINI se puede realizar a travs de la utilizacin de Servlets de Java, los cuales residiran y se ejecutaran sobre la TINI.

93

BIBLIOGRAFA

!" COMER, Douglas E. Redes Globales de informacin con Internet y TCP/IP. Prentice-Hall Hispanoamericana, S.A. Mxico, 1997.

!" DEITEL, H. M. y DEITEL, P. J.. Cmo programar en Java. Prentice-Hall Hispanoamericana, S.A. Mxico, 1998.

!" GEARY, David M. Graphic Java 1.2: Mastering the JFC. Tercera edicin. The Sun Microsystem Press. U.S.A., 1999.

!" LOOMIS, Don. The TINI Specification and Developer`s Guide. Addison Wesley, 2001.

!" ESCOBAR, Anglica M. y SANCHEZ, Hugo A. Implementacin de una Red Inalmbrica usando el protocolo MODBUS. Trabajo de grado, Universidad del Valle. Santiago de Cali, 2001.

94

Enlaces Electrnicos:

!" http://www.modicon.com/openmbus

!" http://www.ibutton.com/TINI

!" http://www.modbus.org

!" http://www.isa.org

!" http://www.win-tech.com

!" http://jmodbus.sourceforge.net

95

ANEXO # 1
Disposicin fsica del montaje final

En la figura siguiente se aprecia la disposicin fsica de tarjetas y cables del montaje final de la red implementada.

!" TARJETA # 1. Esta tarjeta proporciona la interfaz entre las 4 seales RS-485 provenientes del controlador 452 Plus y las dos seales RS-485 provenientes de la tarjeta CPU08. Adems en esta tarjeta se proporcionan las resistencias de acople necesarias para el canal de transmisin y recepcin RS-485. Esta tarjeta posee un conector macho de 7 pines el cual se conecta con la CPU08 y posee dos conectores DB25 machos.

96

!" CABLE # 1. Enlace RS-485. Este cable posee en un terminal un conector DIN de 5 pines que se conecta al controlador 452 Plus y en el otro extremo posee un conector DB25 hembra que se conecta a la tarjeta # 1. Todos los cables que conectan a los diferentes controladores son de este mismo tipo. A continuacin se presenta la descripcin de pines y de seales.

Conector DIN Pin 1: No conectado Pin 2: TxPin 3: Tx+ Pin 4: Rx+ Pin 5: Rx-

Conector DB25

Pin 3: Seal B Pin 9: Seal A Pin 10: Seal A Pin 2: Seal B

!" CABLE # 2. Enlace RS-485. Este cable posee en los dos terminales conectores de 14 pines para cable ribbon. A continuacin se presenta la descripcin de pines y de seales.

Conector CPU08 Pin 14: GND Pin 12: Seal B Pin 10: Seal A

Conector tarjeta #1 Pin 14: GND Pin 12: Seal B Pin 10: Seal A

97

!" CABLE # 3. Enlace RS-232. Este cable posee en los dos terminales conectores de 14 pines para cable ribbon. A continuacin se presenta la descripcin de pines y de seales.

Conector TINI Pin 4: RxD Pin 10: GND Pin 12: -----Pin 13: TxD

Conector CPU08 Pin 4: TxD Pin 10: GND Pin 12: Interrupcin 1 Pin 14: RxD

!" CABLE # 4. Enlace RS-232. Este cable posee en un terminal un conector RJ11 que se conecta al PLC DL05 y en el otro extremo posee un conector DB9 que se une con la tarjeta TINI. A continuacin se presenta la descripcin de pines y de seales.

Conector DB9 Pin 2: RxD Pin 3: TxD Pin 5: GND

Conector RJ11 Pin 4: TxD Pin 3: RxD Pin 1: GND

!" CABLE # 5. Enlace Ethernet. Este cable es el que nos da acceso a una red Ethernet. Posee en ambos terminales conectores RJ45.