IMPLEMENTACION DE UNA RED MODBUS/TCP

IMPLEMENTACION DE UNA RED MODBUS/TCP
ANDRES FELIPE RUIZ OLAYA
UNIVERSIDAD DEL VALLE
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
PROGRAMA DE INGENIERÍA ELECTRÓNICA
SANTIAGO DE CALI
2002
IMPLEMENTACION DE UNA RED MODBUS/TCP
ANDRES FELIPE RUIZ OLAYA
Trabajo de grado para optar por el título de
INGENIERO ELECTRÓNICO
Directores
Ing. ASFUR BARANDICA LOPEZ
Ing. FABIO GERMAN GUERRERO, M. Sc.
UNIVERSIDAD DEL VALLE
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
PROGRAMA DE INGENIERÍA ELECTRÓNICA
SANTIAGO DE CALI
2002
RESUMEN
En este proyecto se desarrolla e implementa una red de instrumentación y
control industrial con conectividad TCP/IP (como por ejemplo Internet), capaz
de ser supervisada y controlada remotamente a través del protocolo
Modbus/TCP usando el sistema embebido TINI de Dallas Semiconductor.
Además se desarrolla una interfaz de usuario gráfica para acceso desde
Internet vía Web .
Nota de Aprobación
El
trabajo
de
grado
titulado
“IMPLEMENTACIÓN
DE
UNA
RED
MODBUS/TCP”, presentado por el estudiante ANDRES FELIPE RUIZ OLAYA,
para optar al título de Ingeniero Electrónico 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 grandísima colaboración en esta etapa final de la carrera y porque de ellos
aprendí mucho.
A todas aquellas personas que me acompañaron a lo largo de la carrera y en la
culminación de este trabajo de grado.
A mis compañeros, profesores y en general a la comunidad universitaria de
Univalle por la experiencia vivida en esta institución.
CONTENIDO
Pag.
0. INTRODUCCIÓN
1
1. EL PROTOCOLO MODBUS/TCP
8
1.1 DESCRIPCIÓN
8
1.1.1 Orientado a conexión
9
1.1.2 Codificación de datos
11
1.1.3 Interpretación del modelo de datos
11
1.1.4 Filosofía de longitud implicada
12
1.2 VENTAJAS DEL PROTOCOLO MODBUS/TCP
13
1.3 ESTRUCTURA DEL PROTOCOLO
14
1.4 ESQUEMA DE ENCAPSULACION
17
1.5 CONFORMACION DE CLASES
17
1.5.1 Comandos Clase 0
18
1.5.2 Comandos Clase 1
18
1.5.3 Comandos Clase 2
19
1.5.4 Comandos específicos de la máquina/red/vendedor
20
1.6 DESEMPEÑO REQUERIDO Y ESPERADO
21
1.7 GUIA DE IMPLEMENTACION DEL CLIENTE Y SERVIDOR
22
1.7.1 Diseño del Cliente
22
1.7.2 Diseño del Servidor
24
2. DESCRIPCION DEL HARDWARE
27
2.1 LA TARJETA TINI
27
2.1.1 Descripción
28
2.1.2 Características
28
2.1.3 Aplicaciones
29
2.1.4 Hardware de la TINI
31
2.1.5 Mapa de memoria del sistema
34
2.1.6 Sistema I/O integrado
36
2.1.7 Software de la TINI
37
2.1.8 Sistema operativo de la TINI
39
2.1.9 El Socket E10
40
2.2 LA TARJETA CPU08
41
2.2.1 Diagrama de bloques
42
2.2.2 Características
42
2.2.3 Programación de la CPU08
43
2.3 EL PLC DL05 DE KOYO
44
2.3.1 Diagrama de bloques
44
2.3.2 Características
45
2.3.3 Modos de operación
45
2.3.4 Mapa de memoria
46
2.3.5 Comunicación
47
2.3.6 Programación
49
2.4 CONTROLADORES 452 PLUS
49
2.4.1 Definición de caracteres especiales
50
2.4.2 Protocolo de Comunicación
50
2.4.2.1 Nivel 1 – El “Wrapping”
51
2.4.2.2 Nivel 2 – Contenido del mensaje
51
2.4.3 Contenido de posiciones análogas del controlador 452 Plus
52
3. DESCRIPCIÓN DEL SOFTWARE
53
3.1 DESARROLLO DE UN SERVIDOR MODBUS/TCP
54
3.1.1 Estructura de Clases
55
3.1.2 Descripción de las Clases
56
3.1.3 Ejemplo de código fuente
59
3.2 DESARROLLO DE UN SERVIDOR WEB
63
3.3 DESARROLLO DE UNA INTERFAZ PARA ACCESO WEB
66
3.3.1 El applet como un cliente Modbus/TCP
67
3.3.2 Sistema de acceso
70
3.3.3 Panel de Control
71
3.4 IMPLEMENTACIÓN DE UN ESCLAVO MODBUS EN LA CPU08 73
3.4.1 Algoritmo de la aplicación para la CPU08
74
3.4.2 La UART implementada por software
79
3.5 LA CPU08 MAESTRO DE UNA RED DE CONTROLADORES
80
3.5.1 Respuestas del controlador 452 Plus a solicitudes
81
3.5.2 Ejemplos de mensajes de lectura y escritura
83
3.6 CONFIGURACION DEL PLC DL05 COMO ESCLAVO MODBUS 84
3.7 CONFIGURACION DE LOS CONTROLADORES 452 PLUS
86
3.7.1 Conexiones físicas
88
4. CONCLUSIONES
89
BIBLIOGRAFÍA
93
ANEXO
95
LISTA DE TABLAS
Pag.
Tabla 1.1 Estructura del prefijo de Modbus/TCP
15
Tabla 1.2 Estructura de mensajes en Modbus/TCP
16
Tabla 1.3 Comandos de la Clase 0
18
Tabla 1.4 Comandos de la Clase 1
19
Tabla 1.5 Comandos Clase 2
19
Tabla 1.6 Funciones dependientes de la máquina
20
Tabla 2.1 Modos de operación del PLC DL05
46
Tabla 2.2 Tipos de memoria del PLC DL05
47
Tabla 2.3 Características del puerto 1 del PLC DL05
48
Tabla 2.4 Características del puerto 2 del PLC DL05
48
Tabla 2.5 Caracteres especiales ASCII del controlador
50
Tabla 2.6 Tipos de mensaje del controlador 452 Plus
52
Tabla 2.7 Posiciones de memoria del controlador 452 Plus
52
Tabla 3.1 Pines utilizados por la tarjeta CPU08
77
Tabla 3.2 Caracteres de error del controlador 452 Plus
81
Tabla 3.3 Ejemplo de trama de lectura del controlador 452 Plus
83
Tabla 3.4 Ejemplo de trama de escritura del controlador 452 Plus
84
Tabla 3.5 Variables de configuración del PLC DL05
84
Tabla 3.6 Funciones MODBUS soportadas por el PLC DL05
86
Tabla 3.7 Configuración de los controladores 452 Plus
87
Tabla 3.8 Interfaz serial del controlador 452 Plus
88
LISTA DE FIGURAS
Pag.
Figura 1.1. Diagrama de la red implementada
4
Figura 1.2 Esquema de encapsulación en Modbus/TCP
17
Figura 2.1 La TINI como un conversor de protocolos
31
Figura 2.2 Esquema del hardware de la TINI
32
Figura 2.3 Mapa de memoria de la TINI
34
Figura 2.4 Esquema del software de la TINI
38
Figura 2.5 Diagrama de bloques de la CPU08
42
Figura 2.6 Diagrama de bloques del PLC DL05
44
Figura 3.1 Modelo cliente / servidor
54
Figura 3.2 Estructura de clases
55
Figura 3.3 Estructura de la interface de transporte
56
Figura 3.3 Programa en Java de un servidor Modbus/TCP
60
Figura 3.4 Ejemplo de código para un servidor Web
64
Figura 3.5 Archivo HTML que carga la applet en un navegador Web
65
Figura 3.6 Código en Java para un cliente Modbus/TCP
69
Figura 3.7 Interfaz del Sistema de Acceso
71
Figura 3.8 Vista del panel de control
72
Figura 3.9 Algoritmo para el programa de la CPU08
75
Figura 3.10 Lectura de bits en la UART implementada
80
Figura 3.11 Configuración del puerto 2 en DirectSOFT
85
UNIVERSIDAD DEL VALLE
FACULTAD DE INGENIERÍA
Programa académico de pregrado de
INGENIERÍA ELECTRÓNICA
Título: Implementación de una red Modbus/TCP
Autor: Andrés Felipe Ruíz Olaya
Directores: Ing. Fabio Germán Guerrero, M. Sc.
Ing. Asfur Barandica López
Grupo de investigación: Percepción y Sistemas Inteligentes.
Area de investigación: Comunicaciones Industriales.
Descriptores: Modbus, Modbus/TCP, Ethernet, TCP/IP, Java, Interfaz Web,
Instrumentación, comunicaciones.
1
0. INTRODUCCION
En el área de las comunicaciones en entornos industriales, la estandarización de
protocolos es un tema en permanente discusión, donde intervienen problemas
técnicos y comerciales. Cada protocolo está optimizado para diferentes niveles de
automatización y en consecuencia responden al interés de diferentes proveedores.
Por ejemplo Fieldbus Foundation, Profibus y HART, están diseñados para
instrumentación de control de procesos. En cambio DeviceNet y SDC están
optimizados para los mercados de los dispositivos discretos (on-off) de detectores,
actuadores e interruptores, donde el tiempo de respuesta y repetibilidad
son
factores críticos1.
Cada protocolo tiene un rango de aplicación; fuera del mismo disminuye el
rendimiento y aumenta la relación costo/prestación.
1
Tomado de “Comunicaciones en entornos industriales”, por Mario Distéfano. Visitar la dirección
http://fing.uncu.edu.ar/investigacion/institutos/IAEI/Cursos2.htm
2
Debido a la no aceptación de un protocolo estándar único en las comunicaciones
industriales, los múltiples buses de campo han perdido terreno ante la incursión de
tecnologías de comunicación emergentes como Ethernet en este área.
La aceptación mundial de Ethernet en los entornos administrativos y de oficina ha
generado el deseo de expandir su aplicación a la planta. Ethernet se está
moviendo rápidamente hacia el mercado de los sistemas de control de procesos y
la automatización, para la interconexión 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 tecnología emergente Fast
Ethernet se pueda aplicar también al manejo de aplicaciones críticas de control2.
Los buses de campo son una forma especial de LAN dedicada a aplicaciones de
adquisición de datos y comando de elementos finales de control sobre la planta.
Los buses de campo típicamente 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 diseñadores optimizan los buses de campo para el
intercambio de mensajes cortos de comando y de control con altísima seguridad y
temporización estricta.
2
Tomado de “Moving Ethernet to plant floors”, por Sam Malizia. Visitar
http://www.isa.org/journals/ic/feature/1,1162,541,00.html
la dirección
3
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 máquinas y permitiendo interoperabilidad entre diversas plataformas. Usar
TCP/IP sobre Ethernet a nivel de campo en la industria permite tener una
verdadera integración con la Intranet corporativa, y de esta forma se ejerce un
estricto control sobre la producción3.
En este proyecto se pretende utilizar un estándar de instrumentación sobre
Ethernet, Modbus/TCP4, para realizar la implementación de una red de control
industrial capaz de ser accedida a través 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 comunicación con gran diversidad de elementos industriales; es
por eso que es de gran importancia trabajar sobre él, y además debido a que en
nuestro medio no se encuentran desarrollos concernientes a este tema.
Arquitectura de la solución
El siguiente diagrama ilustra la red Modbus/TCP implementada, al igual que los
enlaces y la interacción que debe existir entre los diversos elementos que
componen el sistema :
3
Tomado de http://www.modbus.org/modbus_tcp_new.htm
El protocolo Modbus/TCP fue introducido por Schneider Automation. La especificación se
encuentra disponible en http://www.modicon.com/openmbus.
4
4
Figura 1.1 Diagrama de la red implementada
5
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 información y adquirir el conocimiento necesario para implementar,
configurar, mantener y evaluar una red Modbus/TCP.
Objetivos específicos
• Implementar en la tarjeta TINI un servidor Modbus/TCP,
el cual permita a
través 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.
6
• 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 más información de esta tarjeta, consultar la sección 2.1.
Para más información de esta tarjeta, consultar la sección 2.2.
6
• Implementar un esclavo MODBUS en la tarjeta TINI.
• Desarrollar una interfaz de usuario gráfica vía Web, desde la cual sea posible
realizar operaciones remotamente de supervisión 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. Además debe demostrarse la interoperabilidad de la red
probándola 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
estándar y se detalla la manera en que se lleva a cabo su implementación. Aquí
también se presentan las ventajas del protocolo y las características que
proporciona para ser usado en comunicaciones industriales sobre Ethernet.
En la segunda parte “Descripción del hardware”, se presenta en detalle las
características de cada uno de los elementos que conforman la red Modbus/TCP
implementada y el papel que desempeñan en el sistema completo. Se realiza una
7
exposición 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 “Descripción del software”, se describe la forma en que se
desarrollaron los programas y aplicaciones que corren sobre los diversos
elementos de la red, además se explica la funcionalidad que brindan y la
interacción 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.
8
1. EL PROTOCOLO MODBUS/TCP7
1.1 DESCRIPCION
Modbus/TCP es un protocolo de comunicación diseñado para permitir a equipo
industrial tal como Controladores Lógicos Programables (PLCs), computadores,
motores, sensores, y otros tipos de dispositivos físicos 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 comunicación simples y abiertos, destinados para la supervisión y el
control de equipo de automatización. Específicamente, el protocolo cubre el uso
de mensajes MODBUS en un entorno “Intranet” o “Internet” usando los protocolos
TCP/IP8.
7
8
Parte de esta sección es tomado de la especificación en http://www.modicon.com/openmbus
Tomado de http://www.modbus.org
9
La especificación Modbus/TCP define un estándar interoperable en el campo de la
automatización industrial, el cual es simple de implementar para cualquier
dispositivo que soporta sockets9 TCP/IP.
1.1.1 Orientado a conexión.
MODBUS es un protocolo de comunicación “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 además
requiriendo mínima información de recuperación para ser mantenida la transacción
en cualquiera de los dos terminales .
Las operaciones de programación de otro lado, esperan una comunicación
orientada a la conexión, es decir, las máquinas 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).
9
Un socket es una abstracción proporcionada por el sistema operativo que permite a un programa
de aplicación accesar los protocolos TCP/IP.
10
Modbus/TCP
maneja
ambas
situaciones.
Una
conexión
es
inicialmente
establecida en esta capa de protocolo (nivel de aplicación), y esa conexión única
puede llevar múltiples transacciones independientes.
En adición, TCP permite establecer un gran número de conexiones concurrentes,
de este modo el cliente (maestro) puede
ya sea re-usar una conexión
previamente establecida ó crear una nueva, en el momento de realizar una
transacción de datos.
Es interesante analizar porqué el protocolo TCP orientado a la conexión es usado
en lugar del protocolo UDP10 orientado a datagramas. La principal razón es
mantener control de una transacción individual encerrándola en una conexión la
cual pueda ser identificada, supervisada, y cancelada sin requerir acción
específica de parte de las aplicaciones cliente y servidor. Esto da al mecanismo
una amplia tolerancia a cambios del desempeño de la red, y permite que
herramientas de seguridad tal como firewalls11 y proxies puedan ser fácilmente
añadidos.
10
El UDP (User Datagram Protocol) proporciona un servicio de entrega sin conexión, utilizando el
IP para transportar mensajes entre máquinas. Emplea el IP para llevar mensajes, pero agrega la
capacidad para distinguir entre varios destinos dentro de una máquina host.
11
Un firewall (muro de seguridad) se le dice a una configuración de ruteadores y redes colocados
entre la organización interna de una red y su conexión con redes externas a fin de dar seguridad.
11
1.1.2 Codificación de datos.
MODBUS usa una representación “big-endian12” para direcciones y datos. Esto
significa que cuando una cantidad numérica más grande que un byte es
transmitido, el byte más significante es enviado primero. Así, por ejemplo:
0x1234
será
0x12 0x34
1.1.3 Interpretación del modelo de datos.
MODBUS basa su modelo de datos sobre una serie de tablas las cuales tienen
características 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 aplicación, 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
aplicación, de lectura-escritura.
12
Big-endian es un formato en el cual el byte más significativo se encuentra primero.
12
La distinción entre entradas y salidas, y entre datos direccionables al bit y
direccionables a la palabra, no implica algún comportamiento de la aplicación. Es
aceptable y común, considerar las cuatro tablas sobrelapando una con otra, si esta
es la interpretación más natural sobre la máquina (esclavo MODBUS) en cuestión.
1.1.4 Filosofía de longitud implicada.
Todas las solicitudes y respuestas MODBUS están diseñadas en tal forma que el
receptor puede verificar que un mensaje está completo. Para códigos de función
donde la solicitud y respuesta son una longitud fija, el código de función solo es
suficiente. Para códigos de función llevando una cantidad variable de datos en la
solicitud ó respuesta, la porción de datos estará precedida por un campo que
representa el número de bytes que siguen.
Cuando MODBUS es llevado sobre TCP información de longitud se adiciona en el
prefijo (o encabezado) para permitir al receptor reconocer los límites del mensaje,
igual si el mensaje ha sido dividido en múltiples paquetes para la transmisión. La
existencia de reglas de longitud implícitas o explícitas, y el uso de un código de
chequeo de error CRC-3213 (sobre Ethernet) resulta en una probabilidad muy
pequeña de corrupción no detectada sobre un mensaje de solicitud o respuesta.
13
CRC (Cyclic Redundancy Code), verificación por redundancia cíclica.
13
1.2 VENTAJAS DEL PROTOCOLO MODBUS/TCP
•
Es escalable en complejidad. Un dispositivo el cual tiene solo un propósito
simple necesita solo implementar uno ó dos tipos de mensaje.
•
Es simple para administrar y expandir. No se requiere usar herramientas de
configuración complejas cuando se añade una nueva estación a una red
Modbus/TCP.
•
No es necesario equipo o software propietario de algún 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 conversión los cuales no requieren
configuración.
•
Es de muy alto desempeño, limitado típicamente por la capacidad del sistema
operativo del computador para comunicarse. Altas ratas de transmisión son
fáciles de lograr sobre una estación ú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 continuación se describe la forma general de encapsulación 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 código de
función hasta el fin de la porción de datos, tiene exactamente la misma disposición
y significado como en las otras variantes MODBUS, tal como:
MODBUS serial – codificación ASCII
MODBUS serial – codificación RTU
MODBUS PLUS
Las únicas diferencias en esos otros casos son la especificación de los
delimitadores inicial y final del mensaje14, el patrón de chequeo de error y la
interpretación de la dirección.
Todas las solicitudes son enviadas vía TCP sobre el puerto registrado 502. Las
solicitudes normalmente son enviadas en forma half-duplex15 sobre una conexión
dada. Es decir, no hay beneficio en enviar solicitudes adicionales sobre una única
conexión 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 dirección, pero no en forma simultánea.
15
que desean obtener altas ratas de transferencia pueden establecer múltiples
conexiones TCP al mismo destino.
El campo “dirección esclavo” de MODBUS es reemplazado por un byte
“identificador de unidad” el cual puede ser usado para comunicar a través de
dispositivos tales como puentes y gateways, los cuales usan una dirección IP
única para soportar múltiples 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 transacción”, un
número 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 simultáneamente múltiples 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
número el cual debe ser establecido a cero.
16
El “len” especifica el número 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 más
pequeños 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
Posición del Byte
Significado
Byte 0
Identificador de transacción. Copiado
por el servidor – normalmente 0.
Byte 1
Identificador de transacción. Copiado
por el servidor – normalmente 0.
Byte 2
Identificador de protocolo = 0.
Byte 3
Identificador de protocolo = 0.
Byte 4
Campo de longitud (byte alto) = 0.Ya
que los mensajes son menores a 256.
Byte 5
Campo de longitud (byte bajo). Número
de bytes siguientes.
Byte 6
Identificador de unidad (previamente
“dirección esclavo”).
Byte 7
Byte 8 y más
Código de función MODBUS.
Los datos necesarios.
17
1.4 ESQUEMA DE ENCAPSULACION
Modbus/TCP básicamente 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 encapsulación en Modbus/TCP
1.5 CONFORMACION DE CLASES
MODBUS por su naturaleza es ya implementada en muchísimos lugares, por tanto
una ruptura de las implementaciones existentes debe ser evitada.
De esta forma el conjunto de los tipos de transacción 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 también identificadas.
18
Debe anotarse que futuras extensiones al estándar pueden definir códigos de
función adicionales para manejar situaciones donde el estándar existente es
deficiente.
1.5.1 Comandos Clase 0.
Este es el mínimo conjunto útil de funciones, tanto para el maestro como para el
esclavo.
Tabla 1.3 Comandos de la Clase 0
Código
Función
03
Leer múltiples registros holding16.
16
Escribir múltiples registros holding.
1.5.2 Comandos Clase 1.
Este es el conjunto adicional de funciones, el cual es comúnmente implementado
e interoperable. Como fue explicado antes, muchos esclavos deciden tratar
entradas, salidas, registros, y valores discretos como equivalentes.
16
En el protocolo MODBUS , “holding register” representa una cantidad de 16 bits, la cual
representa una posición interna de la memoria.
19
Código
Tabla 1.4 Comandos de la Clase 1
Función
01
Leer estado de salidas discretas.
02
Leer estado de entradas discretas.
04
Leer registros de entrada.
05
Forzar una salida discreta.
06
Prefijar un registro holding único.
07
Leer estados de excepción*.
* Esta función típicamente 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 supervisión y HMI17.
Código
Tabla 1.5 Comandos Clase 2
Función
15
Fijar múltiples salidas discretas.
20
Leer referencia general*.
21
Escribir referencia general*.
22
Enmascarar registro de escritura.
23
Leer/escribir registros**.
24
Leer cola FIFO***.
* Esta función será la más apropiada para manejar grandes espacios de registros y
datos, los cuales carecen de números de referencia.
** Esta función permite la entrada y salida de un rango de registros como una
transacción única. Es la forma más eficiente usando MODBUS para
desempeñar un
intercambio regular de datos tal como con un módulo I/O.
*** Una función 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 específicos de la máquina/red/vendedor
Todas de las siguientes funciones, aunque mencionadas en los manuales del
protocolo MODBUS, no son apropiadas para propósitos de interoperabilidad
porque ellas son dependientes de la máquina.
Tabla 1.6 Funciones dependientes de la máquina
Código
Función
08
Pruebas de diagnóstico.
09
Programación*.
10
Completar la programación*.
11
Leer la palabra de estado del contador de eventos.
12
Leer el registro de eventos de comunicación.
13
Programación**.
14
Completar la programación**.
17
Reportar ID del esclavo.
18
Programación***.
19
Reinicializar enlace de comunicaciones***.
125
Sustitución de firmware.
126
Programación**.
127
Reportar dirección local.
* 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 DESEMPEÑO REQUERIDO Y ESPERADO
No existe una especificación precisa acerca del tiempo de respuesta requerida
para una transacción sobre MODBUS ó Modbus/TCP.
Esto es debido a que se espera que Modbus/TCP sea usado en la más amplia
variedad posible de situaciones de comunicación, desde sistemas I/O esperando
temporización en milisegundos, a enlaces de radio de larga distancia con retardos
de varios segundos.
En general, los dispositivos tales como PLC´s responderán a solicitudes
ingresantes en un tiempo “scan18”, el cual típicamente varía entre 20 y 200 msg.
Desde la perspectiva del cliente, ese tiempo de respuesta debe ser extendido por
los retardos de transporte través 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 conexión de red de área amplia (WAN).
Cualquier tiempo “timeout19” usado en un cliente debe ser más grande que el
máximo tiempo de respuesta razonable, para así evitar una excesiva congestión
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 práctica, los timeouts usados en aplicaciones cliente de alto desempeño
serán probablemente algo dependientes sobre la topología de la red y el
desempeño esperado del servidor. Aplicaciones cliente las cuales no son críticas
en tiempo pueden con frecuencia dejar los valores timeout al establecido por
defecto en TCP, el cual reportará fallo en la comunicación después 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 más 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 sección no será considerado obligatorio para la
implementación particular de un cliente ó servidor. Sin embargo, si son seguidas,
estas políticas facilitarán la integración cuando se implementen sistemas multivendedor y gateways a equipo MODBUS ya instalado.
1.7.1 Diseño del Cliente.
Modbus/TCP está diseñado para permitir que el diseño de un cliente sea tan
simple como sea posible. El proceso básico de manejo de una transacción es
como sigue:
23
•
Establecer una conexión 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 conexión TCP.
Opcionalmente correr un timeout, si se desea ser avisado de problemas de
comunicación más rápido 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 comunicación adicional al destino particular en el futuro
inmediato, cerrar la conexión 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 período máximo para dejar una conexión abierta
en el cliente.
20
Un puerto de protocolo es una abstracción que los protocolos de transporte del TCP/IP utilizan para
distinguir entre varios destinos en una computadora host específica.
24
En el evento que expire el timeout para una respuesta, realizar un cierre unilateral
de la conexión, abrir una nueva, y re-enviar la solicitud. Esta técnica permite al
cliente control sobre la temporización de re-intentos, el cual es superior al
suministrado por defecto por TCP. También permite el uso de estrategias alternas,
tal como enviar la solicitud a una dirección IP alterna, usando una red de
comunicación totalmente independiente, en caso de fallo de un componente de la
infraestructura de la red.
1.7.1 Diseño del Servidor.
Un servidor Modbus/TCP siempre será diseñado para soportar múltiples clientes
concurrentes, sin importar que en su uso previsto solo un único cliente parezca
tener sentido. Esto permite al cliente cerrar y reabrir la conexión a fin de responder
rápidamente 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 tamaño de los buffers de
transmisión y recepción. Un servicio TCP normal usualmente asignará 8K bytes ó
más como un buffer de recepción por conexión. Tal espacio de buffer no tiene
valor en Modbus/TCP, ya que el tamaño máximo 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 múltiples threads
(hilos de control), tal como Java, pueden usar la estrategia multithreaded, descrita
a continuación :
1. Esperar conexiones entrantes sobre el puerto 502 de TCP.
2. Cuando una nueva solicitud de conexión sea recibida, aceptarla y crear un
nuevo thread para manejar la conexión.
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
conexión
sea
cerrada.
Ambas
situaciones
despertarán
al
thread
automáticamente.
•
Analizar el encabezado. Si aparece corrupto, por ejemplo si el campo de
protocolo no es cero ó la longitud del mensaje es más grande que 256,
entonces cerrar unilateralmente la conexión. Esta es la respuesta correcta de
un servidor a una situación donde la codificación 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 válido ó un mensaje de
excepción para usar como una respuesta.
•
Generar el prefijo Modbus/TCP para la respuesta, copiando el campo
“identificador de transacción” desde la solicitud, y recalculando el campo de
longitud.
•
Enviar la respuesta, incluyendo el prefijo Modbus/TCP como un buffer único
para transmisión sobre la conexión establecida.
•
De nuevo volver a esperar el próximo prefijo de 6 bytes, y repetir el
procedimiento.
Eventualmente, cuando el cliente elija cerrar la conexión, la recepción del prefijo
de 6 bytes fallará. En este caso se cierra la conexión 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 continuación 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 desarrollarán 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 Descripción.
La Tiny InterNet Interface (TINI) es una plataforma desarrollada por Dallas
Semiconductor que suministra un medio simple, flexible y económico para diseñar
una extensa variedad de dispositivos hardware capaces de conectarse
directamente a redes corporativas y locales. Las características de la plataforma
son expuestas al desarrollador de software a través de un set de interfaces de
programación de aplicaciones (APIs) en Java, brindando un poderoso entorno de
programación orientado a objetos y facultando al programador en la creación 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 interacción con sistemas remotos y usuarios a través de aplicaciones de red
estándar, tal como browsers Web.
2.1.2 Características.
La TINI es una tarjeta SIMM (31.8mm x 102.9mm) de 72 pines. Es una
implementación hardware con Ethernet y soporta toda la funcionalidad
suministrada por cualquier sistema embebido. La tarjeta incluye las siguientes
características:
29
•
512 Kilobytes de memoria flash para código del sistema crítico.
•
512 Kilobytes de memoria SRAM no-volátil, 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 expansión
paralela.
•
Requiere una fuente de alimentación ú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á diseñada 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,
también está incursionando en el hogar y en entornos educativos. La TINI puede
ser usada para tareas embebidas tradicionales stand-alone, pero la mayoría de
aplicaciones utilizan las capacidades de interconectividad de la tarjeta. Unas
pocas aplicaciones de la tecnología TINI incluyen las siguientes:
30
•
Monitoreo y control de equipo basado en Web. La TINI puede ser usada para
establecer comunicación con equipos específicos, para proveer recolección de
datos y diagnóstico remoto para propósitos tales como el monitoreo sobre la
utilización de un dispositivo particular.
•
Conversión 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 fracción del costo y del tamaño.
•
Sistemas de medición remota. Es posible construir aplicaciones para medición
distribuidas en una red. La TINI estaría equipada con dispositivos de medición
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 automatización de equipo.
•
Monitores ambientales. Usando el soporte construido en la TINI de
interconexión 1-Wire, una aplicación 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, ó quizás algún tipo de interfaz paralela.
La aplicación Java corriendo sobre la TINI desempeña la tarea de comunicación
con el dispositivo en su lenguaje nativo (usando un protocolo de comunicación
específico del dispositivo) y presenta los resultados a sistemas remotos
alcanzables a través 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 estática.
El corazón 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 también provee distintos
pines de propósito general que pueden ser usados para desempeñar tareas de
control simples tales como manejar relés 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 estática contiene el área de datos, la pila (heap), al igual que los
archivos de datos del sistema. La SRAM es no-volátil, ya que posee una circuitería
con batería de respaldo de forma que el contenido de la memoria persiste en
ausencia de alimentación. La batería es una muy pequeña celda de litio.
Otros dispositivos periféricos, aparte de la memoria, pueden también ser
interfazados directamente a los buses de datos y direcciones del microcontrolador
(denominada “expansión I/O paralela” en la Figura 2.2). Dos de tales periféricos
usados en el sistema TINI son un controlador Ethernet y un reloj en tiempo real.
Esta configuración extiende el alcance de los dispositivos embebidos a redes
Ethernet y provee una referencia exacta de tiempo para propósitos específicos.
La batería de respaldo también mantiene corriendo el reloj en ausencia de
potencia, asegurando que un tiempo exacto es siempre leído desde el reloj.
22
El entorno runtime esta compuesto por el sistema operativo y la Máquina Virtual Java (JVM).
34
2.1.5 Mapa de memoria del sistema.
Un mapa de memoria especifica dónde la memoria y otros dispositivos periféricos
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 código.
•
Segmento de datos.
•
Segmento de periféricos.
Figura 2.3 Mapa de memoria de la TINI
35
La figura ilustra los máximos tamaños de segmento soportados por la TINI. La
dirección de inicio del segmento es siempre constante, mientras la dirección final
puede variar de acuerdo al tamaño 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 diseñadores deben evitar los rangos del controlador Ethernet y el reloj, cuando
se adicionen otros dispositivos periféricos.
Existe también un área periférica 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 mayoría de hardware es mapeado en el segmento periférico
porque el microcontrolador puede accesarlo más eficientemente.
36
2.1.6 Sistema I/O integrado.
Un amplio rango de dispositivos no soportan la interfaz a un bus periférico.
Frecuentemente esos dispositivos tienen alguna forma de interfaz serial. Un
soporte para los siguientes protocolos de comunicación serial han sido integrados
dentro del microcontrolador.
•
Comunicación serial. Son soportados protocolos seriales síncronos, utilizando
una interfaz de 2 alambres, y comunicación serial asíncrona, basada en el
estándar RS-232. El microcontrolador de la TINI provee dos circuitos UART
(Universal Asynchronous Receiver Transmitter) integrados, que facilitan la
comunicación.
•
Bus CAN. Originalmente desarrollado en Bosch-Siemens, CAN está ahora
descrito en dos estándares ISO. CAN suministra un bus de comunicaciones
serial confiable que es comúnmente 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 pequeños sensores, actuadores, y elementos de memoria en que todos
comparten el mismo conductor tanto para comunicación como para potencia.
37
•
I/O TTL. Los pines de propósito general del puerto del microcontrolador pueden
ser usados para diversas tareas de control y no están necesariamente atados a
algún tipo de dispositivo serial.
La utilización de las capacidades I/O integradas en el microcontrolador en lugar de
I/O mapeada en memoria, reduce el costo de la comunicación con un dispositivo
externo porque se libera a la CPU de operaciones de lectura y escritura de datos
a un dispositivo periférico.
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 también suministrado con la TINI para liberar a
los desarrolladores de aplicación de tener que preocuparse acerca de los detalles
de la creación de capas de infraestructura que den soporte para la ejecución de
tareas múltiples, pilas de protocolos de red e interfaces de programación de
aplicaciones.
Un
entorno
bien
definido que
suministre
todas
de
esas
características permite al desarrollador enfocarse principalmente sobre los detalles
de la aplicación. De esta forma, un entorno runtime fue desarrollado como parte
integral de la plataforma TINI. Una representación gráfica 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
categorías: un sistema operativo el cual es ejecutado directamente por el
microcontrolador y un API interpretado como bytecodes por la Máquina Virtual de
Java (JVM).
El código 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 programación 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 también librerías nativas que pueden ser cargadas desde una
aplicación para lograr requerimientos estrictos de tiempo real.
2.1.8 Sistema operativo de la TINI.
El sistema operativo de la TINI es la capa más baja del entorno runtime. Es
responsable de la administración de todos los recursos del sistema incluyendo el
acceso a la memoria, planificación de procesos múltiples y threads de ejecución, y
la interacción con componentes hardware internos y externos. A excepción 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.
23
El recolector de basura (Garbage Collector) es un hilo que Java provee, el cual automáticamente
recupera la memoria dinámicamente repartida que ya no se necesita, liberando a los programadores
de incluir enunciados en los programas para ejecutar esta acción.
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 más grandes
y es suficientemente rica en funcionalidad para soportar una implementación
completa del paquete java.net. La pila de protocolo soporta múltiples interfaces de
red, incluyendo Ethernet, para interconexión de alta velocidad en área local, y PPP
(Point-to-Point Protocol) sobre un enlace serial para interconexión remota usando
modem.
2.1.9 El Socket E10.
El Socket E10 es una tarjeta de 160mm x 120mm, cuya función principal es
proveer los conectores físicos para interfazar la TINI a Ethernet, dispositivos
seriales, alimentación. La tarjeta Socket E10 está destinada a ayudar en el
proceso de desarrollo de aplicaciones y suministra los siguientes conectores
físicos:
•
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 conexión a un puerto serial DTE (Data
Terminal Equipment) estándar. Este puerto es típicamente usado sólo para
cargar el software a la memoria flash de la TINI.
41
•
Conector DB9 macho. Este conector provee un puerto serial DTE para
conexión 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 estándar 10Base-T
suministrando conectividad a una red Ethernet.
•
Conector RJ11. El conector RJ11 provee acceso a la red 1-Wire usando cable
telefónico estándar.
•
Jack de potencia. El Socket E10 acepta una fuente de alimentación de 5V DC.
El Socket E10 también suministra el espacio respectivo para circuitos integrados y
componentes discretos para soportar opciones adicionales de I/O tales como
expansión 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.
Según el diagrama de la
Figura 1.1, en esta tarjeta se debe implementar algunas funciones MODBUS
apropiadas para comportarse como un esclavo, y además debe manejar una red
RS-485 de controladores a través 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 Características.
•
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 través de optoacopladores).
•
Puerto serial RS-232 / RS-485.
43
•
Puerto síncrono SPI.
•
2 interrupciones externas.
•
Voltaje de alimentación regulado de +5V.
•
Presenta conectores para expandir las funciones del sistema.
Además, se proporciona un programa bootloader residente en la memoria flash
que carga el programa de aplicación en la RAM externa para propósitos de
desarrollo y depuración, de forma que la aplicación pueda ser fácilmente
modificada.
2.2.3 Programación de la CPU08.
La tarjeta CPU08 se programa directamente en el lenguaje propio del
microcontrolador AT89C52. Opcionalmente, es posible realizar la programación en
lenguaje C y utilizar un compilador cruzado que traslade el código fuente C al
lenguaje del microcontrolador. La utilización del lenguaje C para realizar la
programación depende de los requerimientos de desempeño y tamaño de código
que se necesiten satisfacer.
En este proyecto, la programación 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 características 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 función HSIO (High-Speed I/O) que proporciona este PLC, consiste de
hardware dedicado pero configurable en el DL05. Para más información sobre su
operación consultar el manual del PLC.
2.3.2 Características.
•
8 entradas DC de alta velocidad.
•
6 salidas relé.
•
Conjunto de 129 instrucciones para programación.
•
Memoria de programa de 2K bytes.
•
Memoria de datos de 4K bytes.
•
2 puertos de comunicación RS-232.
•
Soporta los protocolos DeviceNet y MODBUS.
•
Algoritmos PID integrados, con lazo auto-tunning.
•
Módulos opcionales de entrada / salida análogos.
2.3.3 Modos de operación.
El PLC DL05 posee tres modos de operación: modo TERM, modo RUN y modo
STOP. En la Tabla 2.1 se describen los tres modos de operación del PLC.
46
Tabla 2.1 Modos de operación del PLC DL05
Modo
Descripción
(Terminal). Están disponibles los modos de depuración,
programación y ejecución. Los diferentes modos y los
TERM
cambios en la programación pueden ser conmutados a
través del software de programación.
(Ejecución del Programa). La CPU es forzada dentro
RUN
del modo de ejecución 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 categorías :
•
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 aplicación MODBUS.
47
Tabla 2.2 Tipos de memoria del PLC DL05
Tipo de memoria
Cantidad
Rango PLC
del PLC
(decimal)
(octal)
Rango en
Modbus
Tipo de dato
Modbus
(decimal)
Datos discretos
Entradas (X)
256
X0 – X377
2048 - 2303
Entrada
Relés especiales
512
SP0 – SP777
3072 – 3583
Entrada
Salidas (Y)
256
Y0 – Y377
2048 – 2303
Salida
Relés de control (CR) 512
C0 – C777
3072 – 3583
Salida
Timers (T)
128
T0 –T177
6144 – 6271
Salida
Contadores (CT)
128
CT0 – CT177
6400 – 6527
Salida
Bits de status
256
S0 – S377
5120 – 5375
Salida
Valor actual del timer 128
V0 – V177
0 – 127
Registro
Palabras de memoria
(V)
Valor
de
entrada
actual
del 128
V1000 – V1177
512 - 639
contador (V)
Memoria V, dato de 3168
(V)
de
entrada
V1200 – V7377
640 – 3809
usuario (V)
Memoria V, no volátil 128
Registro
Registro
de
retención
V7600 – V7777
3968 - 4095
Registro
de
retención
2.3.5 Comunicación.
El PLC DL05 posee dos puertos de comunicación RS-232. Las características de
los puertos 1 y 2 se muestran en las Tablas 2.3 y 2.4 respectivamente.
48
Tabla 2.3 Características del puerto 1 del PLC DL05
Paquete de programación
DirectSOFT.
Rata de baudios
9600 bps (fijos).
Bits de inicio
1
Bits de datos
8
Paridad
Impar (por defecto), par, ninguna
Bits de parada
1
Comunicación
Asíncrona, half duplex con el DTE.
Protocolos soportados
Dirección del dispositivo
K-sequence, DirectNET y MODBUS
RTU, todos como esclavos.
1 (fija)
Tabla 2.4 Características del puerto 2 del PLC DL05
Paquete de programación
Rata de baudios
DirectSOFT.
300, 600, 1200, 2400, 4800, 9600,
19200 y 38400.
Bits de inicio
1
Bits de datos
8
Paridad
Impar (por defecto), par, ninguna.
Bits de parada
1
Comunicación
Asíncrona, half duplex con el DTE.
K-sequence, DirectNET, MODBUS RTU
Protocolos soportados
(maestro o esclavo) y Non-sequence
(para impresión).
Dirección del dispositivo
1 a 247.
49
2.3.6 Programación.
El PLC DL05 posee dos métodos de programación: RLL (Relay Ladder Logic) y
RLL PLUS (PLUS PROGRAMMING). El PLC puede ser programado con un
paquete de programación avanzado, DirectSOFT, un software basado en
Windows que soporta las características más 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 automatización de procesos. La configuración
de los parámetros del controlador (setpoint, cte. Proporcional, cte. Derivativa, etc.)
pueden ser establecidos localmente a través del panel frontal, ó remotamente a
través de una interfaz serial RS-232, RS-423A, RS-422A, ó RS-485.
La comunicación remota con el controlador se desarrolla serialmente usando un
protocolo asíncrono 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 Definición de caracteres especiales.
Los controladores 452 Plus establecen para la comunicación un conjunto de
caracteres especiales ASCII no imprimibles, mostrado en la Tabla 2.5.
Tabla 2.5 Caracteres especiales ASCII del controlador
Carácter
Código
especial
hexadecimal
< STX >
02
Caracter de inicio de trama.
< ETX>
03
Caracter de fin de trama.
< EOT>
04
Caracter de fin de transmisión.
< ACK >
06
Caracter de reconocimiento.
< LF >
0A
Caracter de nueva línea.
< CR >
0D
Caracter de retorno.
< NAK >
15
Caracter de no reconocimiento.
< SYN >
16
Caracter de sincronización.
< ESC >
1B
Caracter de borrado de línea.
< DEL >
7F
Caracter de borrado de carácter.
Descripción
2.4.2 Protocolo de Comunicación.
El protocolo de comunicación está definido en dos “capas” ó niveles; la primera
define el “wrapping” del mensaje (la delimitación 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 comunicación que se desea establecer. Dos
modos de comunicación son ofrecidos: el modo VDU (Visual Display Unit) y el
modo CRL (Control).
El modo VDU está definido para comunicación 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 comunicación entre un computador y múltiples
controladores. Este modo es más complejo, ya que primero se debe especificar
cual controlador se desea direccionar. La dirección es precedida por un caracter
especial <SYN> que indica al dispositivo receptor que el próximo caracter es
interpretado como la dirección.
En modo CRL los mensajes individuales están 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 análoga, establecer una
variable lógica, leer un valor análogo, leer un valor lógico, al igual que lectura de
un bloque de valores análogos ó lógicos.
52
Tabla 2.6 Tipos de mensaje del controlador 452 Plus
Tipo de mensaje
Descripción
RA
Leer variable análoga.
RL
Leer variable lógica.
SA
Escribir en localización análoga.
SL
Escribir en localización lógica.
DA
Leer 10 posiciones análogas desde la posición de inicio.
DL
Leer 10 posiciones lógicas desde la posición de inicio.
2.4.3 Contenido de posiciones análogas del controlador 452 Plus.
En la Tabla 2.7 se relacionan algunas de las posiciones análogas propias de los
controladores 452 Plus.
Tabla 2.7 Posiciones de memoria del controlador 452 Plus
Posición análoga
Descripción
0
Tipo de instrumento (sólo lectura).
1
Valor medido (sólo lectura).
2
Setpoint.
3
Potencia de salida (0 – 100 %).
7
Banda proporcional (%)(0 - 500.0).
8
Término integral (minutos)(0 – 200.0).
9
Término derivativo (segundos)(0 – 4000).
53
3. DESCRIPCIÓN 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 gráfica para acceso vía Web.
4. Implementación de un esclavo MODBUS en la tarjeta CPU08.
5. Programación de la tarjeta CPU08 como maestro de una red RS-485 de
controladores.
6. Configuración del PLC DL05 como un esclavo MODBUS.
7. Configuración de los controladores 452 Plus.
En las siguientes secciones se describe detalladamente cada uno de los
componentes software y la interacción que existe entre los mismos; además se
presenta código 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 petición desde la red, ejecuta una acción basado en
la petición y devuelve el resultado al solicitante; un programa se convierte en
cliente cuando envía una petición 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, basándose en las indicaciones establecidas en la guía de
implementación descrita en la sección 1.7.1.
La implementación del servidor hace uso de la programación orientada a objetos y
el multithread para aceptar solicitudes concurrentes. La estructura de clases y
parte de la implementación está basada en el proyecto “jmodbus”.24
24
Disponible en Internet en http://jmodbus.sourceforge.net
55
El objetivo del proyecto “jmodbus” es proveer librerías Java para permitir a
dispositivos basados en este lenguaje comunicarse como maestros ó esclavos a
través de ModbusRTU, ModbusASCII ó ModbusTCP. El código es abierto y está
diseñado 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 específicas 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 Descripción de las Clases.
La aplicación 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 código 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 desempeñado por los métodos en la
clase ModbusMaster.
•
Clase ModbusRTUTransport. Clase para implementar un mecanismo de
transporte RTU para comunicación MODBUS. Esta clase permite a un
dispositivo comunicarse serialmente, usando codificación 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 código que es requerido para la recepción y el procesamiento de
solicitudes. Esta clase también 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 recepción y el
procesamiento de solicitudes es desempeñado por los métodos de la clase
ModbusSlave.
•
Clase ModbusTCPTransport. Clase para implementar un mecanismo de
transporte TCP para la comunicación MODBUS. Esta clase permite a cualquier
dispositivo comunicarse vía Modbus/TCP. Esta clase debe implementar los
métodos 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 aplicación principal que se mantiene
esperando por solicitudes de conexión al puerto 502 de TCP, el puerto
registrado de Modbus/TCP, y cuando arriva una petición crea un nuevo hilo
que procesa la transacción, mientras la aplicación continúa 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, delimitación y codificación
de tramas MODBUS desde el medio de transporte y el envío y recepción real
de los datos.
La aplicación desarrollada se comporta como un servidor (ó esclavo)
Modbus/TCP, pero también actúa como un gateway de forma que es capaz de
direccionar solicitudes MODBUS destinados a otros esclavos a través de
MODBUS RTU.
3.1.3 Ejemplo de código fuente.
En esta sección se describen algunos apartes importantes del código fuente de la
aplicación 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 porción del código de la clase ServidorModbusTCP, la cual fue
explicada en la sección 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 creación de una conexión socket TCP/IP se realiza directamente con el
paquete java.net. De ahí que con el enunciado de la línea 1 se cargan las clases
del paquete de trabajo con redes de Java (Java Networking Package).
Las líneas 5, 6 y 7 definen constantes requeridas en la clase ServidorModbusTCP
como el número de puerto y el identificador de unidad.
Para establecer un servidor en Java, se utilizan instancias de las clases
ServerSocket y Socket.
En la línea 13 se declara un objeto de la clase ServerSocket. Este es el objeto
utilizado en la aplicación servidor para escuchar las peticiones que realicen los
clientes. Este objeto no realiza el servicio, sino que crea un objeto Socket en
función del cliente para realizar toda la comunicación a través de él.
En la línea 14 se declara un objeto de la clase Socket. Este es el objeto básico en
toda comunicación a través de Internet, bajo el protocolo TCP. Esta clase
proporciona métodos para la entrada/salida a través de streams.
En la línea 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
programación concurrente.
62
Una instancia de la clase ModbusTCPSlave se declara en la línea 16. Esta clase
fue explicada anteriormente y se ejecuta como un nuevo hilo por cada solicitud de
conexión que recibe el servidor. Por tanto esta clase debe implementar el método
run (ejecutar) de la clase Thread. El código que “realiza el verdadero trabajo” de
un hilo se coloca en su método run.
Con el enunciado de la línea 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 número de clientes que pueden
esperar una conexión y ser procesados por el servidor. Si la cola está llena, las
conexiones de los clientes se rechazarán automáticamente.
En la línea 29 se establece un ciclo while, el cual contiene el bloque de código que
el servidor permanecerá ejecutando siempre, que consiste básicamente en
esperar por solicitudes de conexión y la creación de hilos concurrentes para cada
conexión.
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 método accept( ) de la clase ServerSocket, la cual devuelve un
objeto Socket cuando se establece una conexión. En la línea 32 se ejecuta esta
acción.
63
En la línea 34 se crea un hilo para manejar la conexión, y el programa inicia la
ejecución del hilo invocando el método start (arrancar) de ese hilo (línea 35); a su
vez, start invoca el método 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 aplicación
básicamente implementa la función GET que se define en la especificación del
protocolo HTTP.
El servidor permite manejar múltiples conexiones concurrentemente; el programa
se mantiene escuchando en el puerto de HTTP y cuando llega una petición GET,
se crea un proceso hijo que maneja esa transacción particular y éste devuelve una
página HTML (HyperText Markup Language) al cliente.
En la Figura 3.4 se lista parte del código 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 página 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 código para un servidor Web
La página HTML devuelta por el servidor Web al cliente contiene una applet, la
cual es la que verdaderamente representa la interfaz gráfica de usuario que
permite acceso remoto desde Internet. El desarrollo de esta applet se presenta en
la sección 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 través de Internet, instaladas
automáticamente en la máquina cliente y que se ejecutan localmente como parte
de una página Web.
En la Figura 3.5 se lista el contenido del archivo HTML que define la página 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 desempeño, en el archivo HTML se hace uso de una herramienta
del JDK: el programa JAR para la creación 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 conexión adicional al
servidor. Esto hará que la applet se cargue más rápidamente.
66
3.3 DESARROLLO DE UNA INTERFAZ PARA ACCESO WEB
En esta sección 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 través
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 características:
•
Control de acceso de usuarios; sólo 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 supervisión y control de variables se realizan
utilizando el protocolo Modbus/TCP, por tanto la applet debe codificar las
solicitudes según este estándar.
67
3.3.1 El applet como un cliente Modbus/TCP.
Además de proveer la interfaz gráfica para interacción con el usuario, el applet
también debe comunicarse con un servidor Modbus/TCP. Por tanto, como parte
integral del applet se ha implementado un cliente Modbus/TCP, según las
indicaciones establecidas en la sección 1.7.2.
En Java para establecer la comunicación como cliente se utiliza un objeto de tipo
Socket para conectarse con el servidor, un objeto InputStream para recibir
información del servidor y un objeto OutputStream para enviar información al
servidor.
InputStream (una subclase de Object) y OutputStream (una subclase de Object)
son clases abstractas que definen métodos para realizar operaciones de entrada y
salida respectivamente.
El código en Java que se ilustra en la Figura 3.6 establece comunicación con un
servidor Modbus/TCP remoto, construye una solicitud según el protocolo, envía la
solicitud y la respuesta recibida del servidor es verificada. La solicitud
Modbus/TCP que se implementa en el código de la figura es “Leer múltiples
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 función de MODBUS. Código de función 03.
void Leer_Multiples_Registros (
String dns,
// Dirección IP del servidor
int unidad,
// Identificador de unidad
int referencia,
// Número de referencia (posición)
int cantidad,
// Cantidad de registros a leer
int registros[ ] )
// Buffer para colocar los valores leídos
{
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 leídos
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 conexión socket
socket.close( );
}
catch (Exception e) {
System.out.println ( e.getMessage( ) );
e.printStackTrace( );
return;
}
return;
}
}
Figura 3.6 Código en Java para un cliente Modbus/TCP
En el programa anterior se define una función, Leer_Multiples_Registros, la cual
recibe diversos parámetros que se requieren para construir y enviar la solicitud. A
continuación se describen algunos aspectos relevantes del código.
•
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 “lógicos” de datos se leen en una sola operación de
entrada física y se colocan en un buffer de la memoria. Así, el número de
operaciones de entrada física reales es pequeño en comparación con el
número de solicitudes de lectura emitidas por el programa, mejorando el
rendimiento del sistema.
•
Los métodos 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 utilización 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 dirección 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 librería AWT
(Abstract Window Toolkit) de Java, que es un kit completo con herramientas para
manejo de gráficos como paneles, ventanas, botones, menús, 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 gráficos, 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. Además, 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 cargaría
en un navegador Web.
Figura 3.8 Vista del panel de control
La información que se despliega en el panel de control se actualiza
constantemente; esto se realiza a través de un thread independiente que se
comunica con los elementos remotos de la red, enviándoles solicitudes
Modbus/TCP de lectura. Sin embargo, la información que se visualiza no es en
tiempo real debido a los retardos a través de la red.
73
3.4 IMPLEMENTACION DE UN ESCLAVO MODBUS EN LA CPU08
Como se expuso en la sección 2.2.5, la tarjeta CPU08 puede ser programada en
lenguaje C; la implementación 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 múltiples
registros” (código 16 hexadecimal) y “leer múltiples registros” (código 03
hexadecimal).
Para la aplicación a la que está destinada la tarjeta CPU08, solo se requieren
estas dos funciones ya que el programa básicamente 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 actúa como interfaz entre el protocolo
MODBUS y el protocolo codificado en ASCII de los controladores 452 Plus.
El programa de la CPU08 efectúa la conversión de protocolos de forma que la
solicitud MODBUS de lectura de registros se asocia con el tipo de mensaje RA
(leer variable análoga) del controlador 452 Plus; así mismo, la solicitud MODBUS
de escritura de registros se asocia con el tipo de mensaje SA (escribir en
localización análoga) del controlador 452 Plus. Para una descripción de los tipos
de mensajes del controlador revisar la tabla 2.6 y la sección 3.5.
74
De acuerdo a la sección 2.2.2, la tarjeta CPU08 posee un solo puerto de
comunicaciones RS-232 ó RS-485. La aplicación que se desarrolló para la CPU08
requiere de la existencia de dos puertos de comunicación serial, por tanto uno de
los cuales se implementó por software utilizando dos pines de propósito general,
que simulan las señales Rx y Tx de una UART.
El puerto de comunicaciones RS-485 que tiene la tarjeta se utiliza para establecer
la comunicación 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 información según el estándar
IEEE754 que define el formato para el almacenamiento y la transmisión de datos
flotantes. Cada dato flotante se debe tratar como dos registros holding según el
protocolo MODBUS.
3.4.1 Algoritmo de la aplicación 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 descripción detallada de las diferentes etapas que componen el algoritmo es
presentada a continuación.
•
Inicio. Se establecen los valores para los registros de función especial del
microcontrolador de la tarjeta CPU08.
•
Etapa 1. Esperar a través de la UART implementada por software, una
solicitud MODBUS a ser procesada.
•
Etapa2. verificar la integridad de la trama MODBUS recibida. Básicamente
corroborar el código de chequeo de error (CRC) recibido con el calculado.
Además comprobar que el mensaje es direccionado a la tarjeta.
•
Etapa 3. realizar una discriminación basándose en el campo de código de
función, para enviar el mensaje a la rutina respectiva.
•
Etapa 4. Generar una respuesta de excepción indicando que el código de
función recibido no es soportado por el esclavo MODBUS.
•
Etapa 5. Rutina para procesar la función de “leer múltiples registros”. Se
encuentra conformada por las etapas 7, 10 y 12.
77
•
Etapa 6. Rutina para procesar la función de “escribir múltiples 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 excepción, indicando el tipo de excepción
que se produjo.
•
Etapa 10 y 11. Construir y enviar una solicitud de lectura ó escritura según el
caso al controlador respectivo, teniendo en cuenta el protocolo de
comunicación ASCII que manejan esos dispositivos. Esto se realiza a través
del puerto serial RS-485 de la CPU08.
•
Etapas 12 y 13. A través 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 según el protocolo una respuesta MODBUS a la
solicitud procesada.
•
Etapa 14. Enviar la respuesta a la trama MODBUS recibida, a través de la
UART implementada por software.
78
La aplicación embebida residente en la tarjeta CPU08 se mantiene cíclicamente
esperando por tramas MODBUS y procesando las solicitudes.
En la sección 3.5 se describe detalladamente la codificación de una trama de
solicitud ó respuesta para los controladores 452 Plus, según el protocolo de
comunicación 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 función que desempeñan.
Tabla 3.1 Pines utilizados por la tarjeta CPU08
Puerto
Descripción
P3.5
Simula la señal de recepción de una UART.
P1.3
Simula la señal de transmisión de una UART.
P1.6
Señal de habilitación para el driver RS-485.
P3.0
Pin de recepción de la UART del microcontrolador.
P3.1
Pin de transmisión de la UART del microcontrolador.
P3.3
Interrupción externa que activa la recepción en la
UART implementada.
También son utilizados los dos pines provenientes del driver RS-485 de la CPU08,
que proporcionan las señales A y B del canal diferencial de transmisión y
recepción.
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 aplicación propuesta.
Se hace uso de una interrupción externa para indicarle a la rutina de recepción la
llegada de un byte, y para iniciar el temporizador que genera la señal de reloj.
Cuando arriva el bit de inicio de un byte (nivel lógico 0) se genera la interrupción
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.
Según el protocolo MODBUS RTU, la separación máxima entre bytes dentro de
una misma trama de lectura o escritura es de 3.5 veces el período de reloj; en la
rutina de recepción se desarrolla esta verificación del tiempo de separación. En la
rutina de recepción también se realiza la verificación de los bits de inicio y de
parada para cada byte que llega.
La señal de reloj se establece al doble de la rata de baudios a la cual se realiza la
comunicación, para garantizar que cada uno de los bits son leídos en la mitad del
slot de tiempo y no cerca de los límites del slot donde podría 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 comunicación
codificado en ASCII que entienden esos dispositivos. Referirse a la sección 2.4.2
para una descripción detallada de dicho protocolo.
Para la aplicación a la que está destinada la CPU08, existen dos tipos de
mensajes distintos para comunicarse con los controladores 452 Plus, que se
presentan a continuación.
81
•
Mensaje para leer una variable análoga:
<SYN>Dirección_del_controlador<STX>RA Dirección_de_la_variable<ETX>
•
Mensaje para escribir en una variable análoga:
<SYN>Dirección_del_controlador<STX>SA Dirección_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 réplica 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 acompaña 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
Descripción
Ejemplo*
1
Mensaje inválido
RX 10
3
Posición inválida
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 posición 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 Dirección_de_la_variable<ACK>Dato<ETX><CR><LF>
•
Respuesta a una solicitud de escritura:
<STX>SA Dirección_de_la_variable Dato<ACK><ETX><CR><LF>
Hay que tener en cuenta que un valor análogo que se desee leer o escribir
consiste de un número con un punto decimal opcional, como por ejemplo 12.34 ó
3999; solamente 4 dígitos 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 razón. Por tanto en el programa de
la CPU08 se establece un timeout cada vez que se envíe una trama al controlador,
para evitar que posiblemente se quede esperando eternamente. Si se completa en
timeout, la CPU08 armará una respuesta de excepción y la retornará al dispositivo
maestro.
83
3.5.2 Ejemplos de mensajes de lectura y escritura.
A continuación se presentan diversos ejemplos de solicitudes de lectura y escritura
para los controladores 452 Plus, al igual que las tramas reales que serán enviadas
a estos dispositivos.
•
Leer la constante proporcional del controlador 452 Plus que tiene dirección 1.
En la Tabla 3.3 se observa la trama de solicitud.
Tabla 3.3 Ejemplo de trama de lectura del controlador 452 Plus
Posición del byte
Caracter ASCII
Valor en hexadecimal*
Byte 0
<SYN>
96
Byte 1
1
B1
Byte 2
<STX>
82
Byte 3
R
D2
Byte 4
A
41
Byte 5
Espacio
A0
Byte 6
7
B7
Byte 7
<ETX>
03
* Este valor además de representar al respectivo carácter ASCII, también coloca la
paridad del protocolo (paridad par).
•
Establecer a 50 el setpoint del controlador 452 Plus que tiene la dirección 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
Posición de byte
Caracter ASCII
Valor en hexadecimal*
Byte 0
<SYN>
96
Byte 1
2
B2
Byte 2
<STX>
82
Byte 3
S
53
Byte 4
A
41
Byte 5
Espacio
A0
Byte 6
2
B2
Byte 7
Espacio
A0
Byte 8
5
35
Byte 9
0
30
Byte 10
<ETX>
03
* Este valor además de representar al respectivo carácter ASCII, también coloca la
paridad del protocolo (paridad par).
3.6 CONFIGURACION DEL PLC DL05 COMO ESCLAVO MODBUS
Para realizar la configuración del PLC DL05 como un esclavo MODBUS se han
utilizado las características que se aprecian en la Tabla 3.5.
Tabla 3.5 Variables de configuración del PLC DL05
Interfaz de comunicación
RS-232
Puerto de comunicación
Puerto 2
Dirección de esclavo
Rata de baudios
Bits de datos
Paridad
2
4800
8
ninguna
85
La comunicación del PLC como dispositivo esclavo puede hacerse a través de
cualquiera de los dos puertos de comunicación, sin embargo se optó por utilizar el
puerto 2 porque es más flexible en los parámetros que se le pueden establecer.
Según la sección 2.3.5, el PLC DL05 se programa con DirectSOFT. En la Figura
3.11 se observa la ventana para la configuración del puerto 2, en DirectSOFT.
Figura 3.11 Configuración del puerto 2 en DirectSOFT
La comunicación con el PLC se establece con el protocolo MODBUS en modo
RTU. Los códigos de función 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
Código de función
MODBUS
Función
Tipo de datos en
el PLC DL05
01
Leer un grupo de salidas discretas.
Y, CR, T, CT
02
Leer un grupo de entradas discretas.
05
Cambiar un dato discreto simple.
Y, CR, T, CT
15
Cambiar un grupo de datos discretos.
Y, CR, T, CT
03
Leer múltiples registros.
V
04
Leer múltiples registros de entrada.
V
06
Escribir un valor en un registro simple.
V
16
Escribir en un grupo de registros.
V
X, SP
Para que puedan realizarse operaciones de escritura de registros ó de datos
discretos sobre el PLC a través del protocolo MODBUS RTU, el PLC debe
encontrarse en modo de operación TERM.
3.7 CONFIGURACION DE LOS CONTROLADORES 452 PLUS
Las variables de configuración de los controladores 452 Plus requeridas para
establecer la comunicación serial a través del puerto RS-485 son:
87
•
Rata de baudios.
•
Dirección de comunicaciones.
•
Modo de comunicación ( modo CRL o VDU ).
•
Nivel de protección de los datos.
Desde el panel frontal de los controladores 452 Plus se establecen los valores de
las variables de configuración, usando las funciones CS que se relacionan en la
Tabla 3.7.
Tabla 3.7 Configuración de los controladores 452 Plus
Función
Valor
CS_5
0, 1*
CS_6
3
CS_7**
1
Descripción
Dirección del controlador
( 0 a 1F )
Rata de baudios
( 0-300, 1-1200, 2-4800, 3-9600 )
Modo CRL/VDU y nivel de protección
( 0-VDU, 1-CRL )
* Un solo valor para cada controlador.
** Para mayor información sobre los diversos valores que puede tomar esta función,
revisar el manual del controlador.
Para la comunicación con los controladores 452 Plus se emplea el modo CRL (ver
sección 2.4), debido a que este modo facilita la comunicación con más de un
controlador, lo cual resulta apropiado para la implementación de la subred RS-485
dentro de la red Modbus/TCP.
88
3.7.1 Conexiones físicas.
La interfaz serial RS-485 de los controladores 452 Plus se presenta físicamente a
través de 4 pines que se detallan en la Tabla 3.8.
Tabla 3.8 Interfaz serial del controlador 452 Plus
Número de pin
Señal
4
Tx -
3
Tx +
2
Rx +
1
Rx -
Las señales Tx- y Tx+ conforman el canal diferencial de transmisión y las señales
Rx- y Rx+ conforman el canal diferencial de recepción.
Para realizar la conexión entre la tarjeta CPU08 y la subred RS-485 de
controladores 452 Plus, se unen las señales Tx+ y Rx+ de cada uno de los
controladores con la línea A del driver RS-485 de la CPU08. Igualmente se unen
las señales Rx- y Tx- de cada uno de los controladores con la línea B del driver
RS-485 de la CPU08.
89
4. CONCLUSIONES
•
Ante la incursión de la tecnología Ethernet en el área de los sistemas de
control de procesos y la automatización, para la interconexión a nivel de campo
de sensores, actuadores y controladores, han surgido diversos protocolos para
comunicación industrial sobre Ethernet. Sin embargo, una capa de aplicación
(según el modelo de referencia OSI) estándar con un modelo de objetos
común, no existe. Modbus/TCP es un estándar “de-facto” y está ampliamente
extendido y aceptado; Pero además 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 añade
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 simultáneamente desde una posición única.
90
Además del monitoreo de variables (como la variable corriente del proceso),
los parámetros 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;
además, todo el proceso de programación y depuración de las aplicaciones se
desarrolló en un PC, para posteriormente transportar el código a la tarjeta,
agilizándose la creación de los programas.
•
Con la implementación 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 razón de su alta difusión en entornos industriales.
Además, 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, demostrándose 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 estándar
Modbus/TCP.
91
•
El monitoreo continuo de datos ó “streaming data” no es muy eficiente con el
protocolo Modbus/TCP, debido básicamente 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,
incrementándose considerablemente el tráfico en la red cuando se monitorea
en todo momento un esclavo Modbus/TCP particular. La solución para la
supervisión de datos continuo sobre una red Ethernet es la utilización del
protocolo de transporte UDP.
•
Como una proyección futura del presente trabajo sería 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
información. Con la tarjeta TINI, básicamente este estándar se utilizaría para
que una base de datos con soporte XML (actualmente casi todas lo tienen) se
comunique con ella y acceda continuamente a la información proveniente de
los procesos. Esta información es almacenada en las tablas internas de la base
de datos, y de esa forma es posible llevar registros, históricos, tendencias,
gráficos, 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 código abierto.
92
•
La interfaz gráfica de usuario para la supervisión y control de la red
Modbus/TCP desde Internet que se desarrolló como un applet de Java también
es posible enfocarla desde un punto de vista diferente: El mecanismo de
interacción entre al usuario en la Web y la plataforma TINI se puede realizar a
través de la utilización de Servlets de Java, los cuales residirían y se
ejecutarían sobre la TINI.
93
BIBLIOGRAFÍA
•
COMER, Douglas E. Redes Globales de información con Internet y TCP/IP.
Prentice-Hall Hispanoamericana, S.A. México, 1997.
•
DEITEL, H. M. y DEITEL, P. J.. Cómo programar en Java.
Prentice-Hall Hispanoamericana, S.A. México, 1998.
•
GEARY, David M. Graphic Java 1.2: Mastering the JFC. Tercera edición.
The Sun Microsystem Press. U.S.A., 1999.
•
LOOMIS, Don. “The TINI Specification and Developer`s Guide”.
Addison – Wesley, 2001.
•
ESCOBAR, Angélica M. y SANCHEZ, Hugo A. Implementación de una Red
Inalámbrica usando el protocolo MODBUS.
Trabajo de grado, Universidad del Valle. Santiago de Cali, 2001.
94
Enlaces Electrónicos:
•
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
Disposición física del montaje final
En la figura siguiente se aprecia la disposición física de tarjetas y cables del
montaje final de la red implementada.
•
TARJETA # 1.
Esta tarjeta proporciona la interfaz entre las 4 señales RS-485 provenientes del
controlador 452 Plus y las dos señales RS-485 provenientes de la tarjeta
CPU08. Además en esta tarjeta se proporcionan las resistencias de acople
necesarias para el canal de transmisión y recepción 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 continuación se presenta la
descripción de pines y de señales.
Conector DIN
Conector DB25
Pin 1: No conectado
•
Pin 2: Tx-
Pin 3: Señal B
Pin 3: Tx+
Pin 9: Señal A
Pin 4: Rx+
Pin 10: Señal A
Pin 5: Rx-
Pin 2: Señal B
CABLE # 2. Enlace RS-485.
Este cable posee en los dos terminales conectores de 14 pines para cable
ribbon. A continuación se presenta la descripción de pines y de señales.
Conector CPU08
Conector tarjeta #1
Pin 14: GND
Pin 14: GND
Pin 12: Señal B
Pin 12: Señal B
Pin 10: Señal A
Pin 10: Señal A
97
•
CABLE # 3. Enlace RS-232.
Este cable posee en los dos terminales conectores de 14 pines para cable
ribbon. A continuación se presenta la descripción de pines y de señales.
•
Conector TINI
Conector CPU08
Pin 4: RxD
Pin 4: TxD
Pin 10: GND
Pin 10: GND
Pin 12: ------
Pin 12: Interrupción 1
Pin 13: TxD
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
continuación se presenta la descripción de pines y de señales.
•
Conector DB9
Conector RJ11
Pin 2: RxD
Pin 4: TxD
Pin 3: TxD
Pin 3: RxD
Pin 5: GND
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.