Download Capítulo 1 RESUMEN

. Resumen
i
Capítulo 1 RESUMEN
El proyecto Desarrollo en Java de un sistema de acceso remoto a Modbus.
Implementación Web y Java del sistema para CP2003, tiene el objetivo final de
desarrollar una aplicación que lea e interprete las medidas del dispositivo CP2003
por medio de Internet. Este dispositivo tiene la funcionalidad general de tomar
medidas e información de una red eléctrica, obteniendo datos de intensidad, voltaje,
etc., que puedan permitir un estudio, por ejemplo del consumo. Este dispositivo
funciona mediante el protocolo de tipo serie Modbus, ampliamente utilizado por los
entornos industriales para el control de sus equipos.
Para desarrollar este objetivo final, se ha decidido estructurar el proyecto en dos
grandes categorías o subproyectos. El primero, correspondería a la aplicación que
sabe cómo comunicarse con el dispositivo (vía Modbus), obtiene la información
requerida de él y sabe como interpretarla, en otras palabras una especie de
controlador. El segundo va a consistir en el desarrollo de un método que nos permita
abstraernos de los detalles de la comunicación Internet. Esta decisión ha derivado en
el diseño y programación de una aplicación cliente-servidor. El servidor, que reside
en el sistema local conectado a la red Modbus, va a recuperar y administrar detalles
de la red Modbus, y va a gestionar las conexiones entrantes TCP/IP. En el lado del
cliente se implementará una clase que ofrezca acceso las funciones de la aplicación
del servidor sobre la red Modbus. Esta herramienta no implementará ningún tipo de
particularidad del manejo del CP2003, con el fin de ofrecer sus utilidades al
desarrollo de otras aplicaciones Modbus.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
. Resumen
ii
Los resultados finales obtenidos son:
RemModbus será una aplicación que de forma remota y local, administra una red
Modbus cualquiera. Además facilita el desarrollo de nuevas aplicaciones.
WebCP2003 será todo un sistema de control definido sobre un servidor Web, para
demostrar la potencia de RemModbus, que esta diseñado para obtener de forma
remota información de uno o varios dispositivos CP2003
RemCP2003 será un programa Java para la ejecución de consultas definidas sobre
un CP2003. Las tramas se interpretarán.
RemBridge permitirá la creación de una comunicación entre una aplicación Modbus
cualquiera y un dispositivo Modbus, a través de Internet, usado la tecnología
RemModbus desarrollada anteriormente. En la parte del cliente, se ejecutará
RemBridge, el cual, se comunicará con un puerto COM virtual. Una aplicación
Modbus local cualquiera, se conecta a otro puerto virtual COM como si el
dispositivo estuviera conectado a ese puerto. De esta forma RemBribge hace las
veces de dispositivo Modbus, y realiza las conexiones pertinentes con RemModbus
en el servidor, que llevará a cabo la comunicación real.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
. Abstract
iii
Capítulo 2 ABSTRACT
The Project named Java Development of a system of remote access to Modbus.
Implementation Web and Java of the system for CP2003, has the last and final goal
of developing an application able to read and interpret measure information of the
CP2003 device via the Internet. This device has the overall functionality of taking
information from a power grid, as drawing intensity, voltage, etc.. That may allow a
study of the situation, for example, for consumption. This device works through the
serial Modbus protocol, widely used in industrial environments to control their
devices.
To develop this ultimate goal, it was decided to structure the project into two big
categories or sub-projects. The first would correspond to the application that knows
how to communicate with the device (via Modbus), obtains the information required
of him and knows how to interpret it, in other words a sort of controller. The second
will be to develop a method that allows us to abstract from the details of Internet
communication. That decision has resulted in the design and scheduling of a clientserver application. The server, which resides in the local system connected to the
network Modbus, will manage and retrieve details of the Modbus network, and will
manage incoming connections TCP / IP. On the client side it must be necessary to
implement a class that offers access functions of the application server on the
network Modbus. This tool will not implement any special handling of CP2003 in
particular, in order to offer their profits to develop other applications Modbus.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
. Abstract
iv
The final results are the following:
RemModbus will be an application that manages any Modbus network both
remotely and locally. In addition, it will facilitate the development of new Modbus
applications.
WebCP2003 will be a control system defined on a Web server, to demonstrate the
power and versatility of RemModbus, which is designed to remotely obtain
information from one or more devices CP2003.
RemCP2003 will be a Java application for carrying out defined consultations on a
CP2003. The responses will be interpreted.
RemBridge will allow the creation of a communication between a Modbus
application and any Modbus device, via the Internet, using the technology developed
RemModbus earlier. On the client side, shall be executed RemBridge, which will
communicate with a virtual COM port. Any local Modbus application is connected to
another virtual COM port, as if the device was connected to that port. Thus
RemBribge acts as a Modbus device, and make relevants connections with
RemModbus on the server, which carried out the actual communication.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
. Índice
v
ÍNDICE
Memoria ..................................................................................................................... 1
Capítulo 1
Introducción....................................................................................... 2
1
Estado del arte.......................................................................................................... 3
2
Motivación del proyecto ........................................................................................ 7
2.1 Modbus sobre TCP ..................................................................................................................7
2.2 Uso del CP2003.......................................................................................................................9
3
Motivación del proyecto ...................................................................................... 11
3.1 Desarrollo de un entorno para el desarrollo de aplicaciones remotas Modbus ......................11
3.2 Desarrollo de aplicaciones Modbus remotas..........................................................................13
3.3 Controlador remoto del CP2003............................................................................................15
4
Identificación de Necesidades............................................................................ 16
4.1 Objetivos ...............................................................................................................................16
4.2 Alcance de la aplicación.........................................................................................................19
4.3 Tipología de los usuarios .......................................................................................................20
4.4 Restricciones..........................................................................................................................21
5
Metodología de desarrollo .................................................................................. 22
6
Recursos, herramientas y tecnologías empleadas ........................................... 23
7
Estudio de la arquitectura.................................................................................... 25
7.1 RemModbus y RemBridge ....................................................................................................25
7.2 RemCP2003 y WebCP2003 ..................................................................................................25
7.3 Arquitectura extendida de la aplicación. ...............................................................................26
Capítulo 2
1
RemModbus ..................................................................................... 27
Introducción ........................................................................................................... 27
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
. Índice
2
vi
Diseño ..................................................................................................................... 28
2.1 Diseño de la Base de Datos....................................................................................................29
2.2 Diseño del protocolo RemModbus.........................................................................................30
2.2.1 Proceso de conexión y establecimiento de usuario:.............................................................32
2.2.2 Otras transacciones cliente – servidor. Lógica de confirmaciones......................................33
2.2.3 Lista de transacciones.........................................................................................................34
2.3 Diseño de RemModbus Servidor...........................................................................................36
2.3.1 Lógica del enlace físico con los puertos del protocolo Serie.................................................36
2.3.2 Lógica de conexión de equipos remotos...............................................................................37
2.3.3 Diseño de control de estado de la red..................................................................................37
2.3.4 Lógica de colas. ...................................................................................................................40
2.3.5 Lógica de la comunicación Modbus....................................................................................42
2.3.6 Diseño de control de obtención de respuestas.....................................................................43
2.3.7 Lógica del descubrimiento de dispositivos conectados a la red (Finding)...........................44
2.3.8 Lógica del polling. ..............................................................................................................45
2.3.9 Lógica de transmisión de tramas. CRC. .............................................................................46
2.4 Diseño de RemModbus Cliente .............................................................................................47
3
Programación y pruebas ...................................................................................... 48
3.1 Programación del acceso a la BBDD .....................................................................................51
3.2 Programación del protocolo RemModbus..............................................................................52
3.3 Programación de RemModbus Servidor................................................................................55
3.3.1 Programación de gestión conexión con protocolo serie: Enlace.java ..................................56
3.3.2 Programación de gestión de conexiones remotas................................................................56
3.3.3 Programación de gestión de estado: Estado.java ................................................................58
3.3.4 Programación de colas........................................................................................................60
3.3.5 Programación de comunicación Modbus y control de obtención de respuestas. ................62
3.3.8 Programación del CRC.......................................................................................................67
3.4 Programación de RemModbus Cliente..................................................................................69
4
API RemModbus................................................................................................... 70
Capítulo 3
WebCP2003, RemCP2003 & RemBridge...................................... 71
1
Introducción ........................................................................................................... 71
2
Requerimientos funcionales ............................................................................... 72
3
Requerimientos no funcionales ......................................................................... 73
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
. Índice
vii
4
Modelo de dominio .............................................................................................. 73
5
Diagrama de casos de uso.................................................................................... 74
6
Descripción de los casos de uso.......................................................................... 75
7
Diagramas de secuencia....................................................................................... 83
7.1 Procesos de login y logout .....................................................................................................83
7.2 WelcomeServlet .....................................................................................................................85
7.3 Ver medidas de un dispositivo...............................................................................................87
7.4 Editar medidas.......................................................................................................................90
7.5 Administrar usuarios ............................................................................................................91
7.6 Arrancar procesos en el servidor ...........................................................................................92
8
RemCP2003............................................................................................................. 93
9
RemBridge.............................................................................................................. 94
Capítulo 4
Resultados/Experimentos .............................................................. 95
1
RemModbus........................................................................................................... 95
2
WebCP2003............................................................................................................. 96
3
RemCP2003............................................................................................................. 96
4
RemBridge.............................................................................................................. 96
5
Experimentos.......................................................................................................... 97
Capítulo 5
Conclusiones.................................................................................... 98
Capítulo 6
Futuros desarrollos....................................................................... 100
Capítulo 7
Estudio Económico ....................................................................... 103
1
Planificación previa ............................................................................................ 103
2
Uso real aproximado del tiempo invertido en el proyecto .......................... 104
3
Valoración económica ........................................................................................ 104
Bibliografía............................................................................................................ 105
Anexo I Manuales de usuario.............................................................................. 107
Capítulo 1
API de RemModbus ...................................................................... 108
pfc_dsm.RemModbus Class SerialPort .................................................................. 108
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
. Índice
viii
Capítulo 2
Manual de RemModbus ............................................................... 112
Capítulo 3
Manual de WebCP2003 ................................................................ 116
1
Entrar en la aplicación............................................................................................. 116
2
Sistema inteligente de interacción........................................................................... 117
3
Interacción simple ................................................................................................... 118
4
Administración del polling y obtención de medidas............................................... 119
5
Administración de usuarios..................................................................................... 121
5.1 Editar usuario. ....................................................................................................................121
5.2 Borrar usuario .....................................................................................................................122
5.3 Añadir usuario ....................................................................................................................123
Capítulo 4
Manual de RemCP2003 ................................................................ 124
Capítulo 5
Manual de RemBridge.................................................................. 126
Anexo 2 CP200X Communication Protocol...................................................... 127
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Índice
1
MEMORIA
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
2
Capítulo 1 INTRODUCCIÓN
En la introducción se van a estudiar tanto las soluciones alternativas a ciertas partes
del proyecto basadas en otros trabajos previos o en otras tecnologías existentes, como
las soluciones tomadas por el equipo de desarrollo. Se recomienda la lectura del
resumen ofrecido anteriormente, para tener una visión general del proyecto y facilitar
la comprensión de éste.
Como ejemplo, hemos visto anteriormente que uno de los pilares sobre los que se
fundamenta este proyecto, consiste en el desarrollo e implementación de un sistema
que permite la comunicación de cualquier aplicación con la red Modbus. Aquí
veremos por qué este punto es interesante y por qué se ha decidido implantar.
Más adelante veremos los objetivos a alcanzar, con una breve descripción, la
metodología de desarrollo del proyecto, sus fases, las herramientas, tecnologías y
recursos que se han utilizado durante todo el ciclo de desarrollo e implementación,
etc.
En general durante la introducción, distinguiremos entre las dos grandes partes del
proyecto:
1. Temas relacionados con Modbus sobre TCP y su programación.
2. Temas relacionados con el CP2003 y su uso remoto.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
3
1 Estado del arte
Se establecerá el entorno tecnológico anterior al desarrollo del proyecto,
desarrollando además las diferentes soluciones disponibles a los problemas
planteados.
Antes de entrar en el tema del funcionamiento de una red Modbus sobre una red
TCP/IP o en el dispositivo CP2003, es conveniente describir Modbus: qué es, cómo
funciona y para qué se utiliza.
El protocolo Modbus es un protocolo abierto, lo que significa que puede ser utilizado
gratuitamente por los desarrolladores. Aprovechándose de esto y de su sencillo
diseño y versatilidad, Modbus se ha convertido desde su creación en 1979 en el
estándar de facto de entornos industriales, siendo utilizado para la comunicación
entre señales de instrumentación o dispositivos de control y un controlador principal
o un sistema de recogida de datos, como por ejemplo, y en este caso, un ordenador.
Si tratamos de localizar las competencias de una aplicación Modbus en el modelo
OSI, vamos a ver que el protocolo se acomoda en dos niveles,
o
Nivel de aplicación (aplication layer), donde trabajarían los
programas que utilizan los dispositivos e interpretan los datos de
dichos instrumentos. (Ej: Windmill, Hyperterminal, etc.).
o
Nivel de protocolo (data-link layer), donde se localizaría el
intercambio de tramas básicas del protocolo Modbus.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
4
APLICACIÓN
MODBUS
NIVELES OSI
7
Aplicación
SI
Protocolo de aplicación
6
Presentación
NO
5
Sesión
NO
4
Transporte
NO
3
Red
NO
2
Enlace
SI
Tramas Modbus
1
Físico
SI
RS485 o RS232
Figura 1: Niveles OSI y aplicaciones Modbus
Este protocolo se basa en una arquitectura sin estados Cliente-Servidor
(denominados maestro y esclavo respectivamente), donde cada dispositivo tiene un
número de esclavo que se utiliza a modo de dirección. Modbus permite ver a cada
dispositivo conectado como un banco de registros contiguos. Cada registro tiene una
dirección de 16 bits dentro del rango 0x0000 a 0xFFFF, y tiene un tamaño.
Dependiendo de cada dispositivo, almacenará un determinado tipo de información
(en el caso del CP2003, tensión, intensidad, etc.) o tendrá una determinada función
(para el CP2003, activar o desactivar un relé, disparar una alarma, etc.). Modbus
representa direcciones y datos mediante big-endian. Esto se traduce en que el bit más
significativo es enviado primero, luego a la hora de transmitir una cantidad mayor
que un Byte, los 8 primeros bits se enviarán antes (Por ejemplo, 0x1F4E será enviado
como 0x1F 0x4E).
Como medio físico de transmisión, el protocolo puede utilizar tanto RS232, como
RS485, ambos medios de tipo serie. RS232 es usado para comunicaciones de corta
distancia punto a punto (así como RS422, el cual es una extensión “bidireccional” de
RS232 para entornos industriales), mientras que RS485, además de permitir
distancias mas largas, puede ser utilizado para redes multipunto utilizando el
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
5
paradigma Maestro-Esclavo anteriormente mencionado. Lógicamente, el medio de
transmisión más utilizado, teniendo en cuenta esta información es RS485.
La comunicación se basa en el paradigma Request-Response, de lo que se denomina
comúnmente PDU (Protocol Data Unit). El protocolo permite mediante tramas,
consultar o actualizar el valor de dichos registros. La trama de petición es recibida
por todos los dispositivos de la red, pero solo es procesada si la trama esta dirigida al
identificador del instrumento que la recibe, enviando una respuesta modificando tan
solo el PDU. En resumen, cada trama de petición obtiene solo una trama de
respuesta, a no ser que haya un error de trama, en cuyo caso no se obtiene ningún
tipo de respuesta.
Figura 2: Comunicación Modbus
A
continuación
se
muestra
una
representación
sencilla
de
una
trama
Modbus:
ID
CMD
INFO
CRC
1 Byte
1 Byte
n Bytes
2 Bytes
Figura 3: Trama Modbus RTU
o
ID (1Byte) es el número de esclavo, que hace las veces de dirección.
Es posible que haya dos dispositivos con el mismo slave number dentro de la
red, por lo que hay que tenerlo en cuenta a la hora de introducir un nuevo
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
6
dispositivo, y programar su dirección adecuadamente. Se permite direccionar
hasta un máximo de 63 esclavos con RS485.
o
CMD (1Byte) es el tipo de orden enviado al esclavo. Hay dos tipos
básicos de órdenes: Lectura/Escritura de/en los registros del esclavo y
órdenes de control (reset, start/stop, etc.)
Figura 4: Comandos Modbus
o
INFO (nBytes) definido anteriormente como PDU, contiene la
información necesaria para la ejecución de la orden indicada en CMD. Esta
puede estar organizada en dirección del primer byte, y número de bytes a
escribir o leer en caso de Lectura/Escritura o podrían ser códigos de
subfunciones para el caso de ordenes de control.
o
CRC (2Bytes) Mecanismo de control de errores de transmisión (cyclic
redundancy check)
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
7
2 Motivación del proyecto
2.1 Modbus sobre TCP
Existe un método para acceder remotamente a la red Modbus vía TCP/IP: el
protocolo Modbus/TCP. Éste no es más que una extensión de Modbus, introducida
por Schneider Automation, que encapsula el las tramas Modbus sobre tramas TCP
para permitir su envío y recepción a través de Internet o una intranet. De igual forma
que Modbus, es abierto y se ha convertido en el protocolo de facto para este tipo de
comunicaciones. A continuación se va a describir como se encapsularía en
Modbus/TCP una trama Modbus de petición o respuesta. Estas tramas poseen una
cabecera compuesta por 6 Bytes divididas en tres campos, como se aprecia en el
gráfico.
TRAMA
ID
CMD
ID DE PROT
LONGITUD
INFO
CRC
MODBUS
ID TRANS
TRAMA MODBUS
TRAMA
MODBUS/TCP
Figura 5: Trama Modbus RTU encapsulada sobre Modbus/TCP
Posición del Byte y su 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 (ID), previamente dirección esclavo.
Byte 7 - Código de función Modbus (CMD).
Byte 8+ - Los datos necesarios.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
8
Las soluciones comerciales que utilizan Modbus/TCP ofrecen dos tipos de
arquitectura en función de en que lado se deseen situar los dispositivos maestros, si
en la parte Serie o en la parte TCP. La arquitectura más utilizada es aquella en la que
los dispositivos maestros, es decir, los dispositivos que solicitan la información de
los esclavos, están en la parte TCP.
Modbus Master 1
(Cliente)
Esclavo 1
INTERNET ó
INTRANET
TCP/IP
RS232
Modbus TCP
Modbus RTU
(Servidor)
(Maestro)
Esclavo 2
TCP/IP
Modbus Master 2
(Cliente)
RS485 /
RS422
Esclavo 3
Figura 6: Arquitectura Modbus/TCP. Maestros en el lado TCP
Para poder implementar el protocolo Modbus/TCP resulta necesario adquirir la pieza
fundamental que hace funcionar esta arquitectura, que es un elemento hardware que
cumple la función de pasarela entre el protocolo TCP y el protocolo Modbus. Este
gateway, normalmente y dependiendo de la empresa que lo proporcione, suele incluir
embebido un sistema de páginas Web que permite navegar a través de los
dispositivos de la red y mostrar el estado de sus registros como si estuviéramos
utilizando un terminal de operaciones. Otros gateways son programables, por
ejemplo en Java y/o permiten instalar aplicaciones o servidores Web en su interior,
optimizando así el uso de las características de un dispositivo concreto al que se
conecte.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
9
2.2 Uso del CP2003
El Multiconvertidor Programable CP200X es un equipo de la empresa española
SACI, que recibe señales de energía de una red eléctrica, las mide y procesa, y las
envía a distancia mediante tres salidas de tipo analógico, dos salidas de tipo digital
todo o nada y opcionalmente, una salida serie de comunicaciones con enlace hacia un
ordenador o dispositivo central de control, accesible mediante el protocolo Modbus.
Las salidas analógicas pueden ser configuradas para representar cualquiera de las
variables medidas. Asimismo, las salidas digitales pueden representar o bien
impulsos correspondientes a la energía consumida, o bien una señal de alarma sobre
alguna de las variables medidas.
SACI ofrece por medio de su página Web (http://www.saci.es) una herramienta
software para el manejo dentro de la red local del dispositivo. Por otra parte para
utilizar esta herramienta es necesario obtener previamente una licencia, de modo que
no puede utilizarse de forma gratuita, y no ha podido ser probada.
Red Eléctrica
Sistema de Control
CP2003
Figura 7: Conexión básica del CP200X
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
10
Datos de información técnica:
El empleo de microprocesador permite un proceso de medida totalmente digital. El
Microprocesador controla el convertidor A/D, toma las muestras, las almacena, y las
procesa, obteniendo los valores de las variables básicas, de la forma siguiente:
Ecuación 1: Ecuaciones de cálculo de medidas
I i2, j
Vi 2,j
∑
∑
Vi = 32 I i = 32 Si = Pi 2 + Qi2
(V
∑
P=
i, j
i
* Ii , j )
32
Qi =
∑ ((V
− 8) * I i , j )
i, j
32
Para la medida de frecuencia se dispone del temporizador programable del micro,
que mide el periodo de la señal de red, entre dos pasos por cero sucesivos. La
determinación
de
la
frecuencia
permite
que
el
microprocesador ajuste el tiempo de toma de muestras, de
forma que el equipo puede trabajar indistintamente entre
los extremos del rango 45 - 65 Hz.
Una memoria EEPROM tipo serie se encarga de almacenar
los datos de configuración del equipo, tanto en lo que se refiere a datos de usuario,
como a los de calibración del equipo. El multiconvertidor además ofrece tres tipos de
salida:
Serie: La salida de comunicaciones, puede ser bien RS232, o RS485. No esta aislada
respecto de la analógica S2, pero si del resto.
Analógicas: Las salidas analógicas se encuentran asimismo aisladas del resto de
circuitos, y disponen de una fuente de alimentación individual mediante
convertidores CC/CC.
Digitales: Dos salidas digitales a base de relés se pueden utilizar, para envío de
pulsos de energía a distancia, o como señales de contactos maniobrados desde el
PLC o PC.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
11
3 Motivación del proyecto
3.1 Desarrollo de un entorno para el desarrollo de aplicaciones remotas
Modbus
Este primer apartado justificara la creación de un sistema que facilite el desarrollo de
aplicaciones remotas en Java, para permitir el acceso a la red Modbus a través de
Internet o intranet.
La motivación más importante de esta primera parte del proyecto es que va a permitir
a futuros usuarios desarrollar fácilmente aplicaciones que trabajen sobre redes o
dispositivos Modbus, sin tener la necesidad de utilizar una solución comercial que
incorpore una pasarela, y evitando de esta forma tener que incluir otro dispositivo
hardware en la red, con el gasto y las complicaciones que eso implica. Solo será
necesario un ordenador típico con Microsoft Windows y un puerto serie típico
RS232 ó RS485, para que se conecte a la red y haga las veces de servidor, o de
gateway.
Muy importante es también, que no solo se pretende establecer una comunicación,
sino que se pretende desarrollar todo un entorno capacitado para recolectar
información de la red, y traspasar las fronteras del protocolo ofreciendo servicios de
control de acceso y de control y recuperación de errores, cosa que un protocolo sin
estados y sin capa OSI de transporte como es Modbus, no posee.
Además se pretende facilitar la labor de los programadores, evitándoles el estudio del
protocolo ya desarrollado Modbus/TCP, descrito con anterioridad, que sería
necesario para desarrollar cualquier aplicación remota. Muchos ingenieros y
desarrolladores de software industrial, no están familiarizados en comunicaciones
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
12
TCP/IP y ven cómo sus trabajos para la administración de estas redes típicamente
industriales, tienen que quedarse limitados al entorno físico de la red.
Gracias a esta utilidad Java, se podrá potenciar el desarrollo de aplicaciones remotas
por parte de todos desarrolladores que hemos mencionado antes, ya que pretendemos
abstraer al diseñador o programador de todo el entorno de comunicación de manera
que no tenga que preocuparse por ningún tema de protocolos de Internet. También
podremos asegurar que estos podrán abstraerse de trabajar a nivel de puertos serie.
Esto se suele llevar a cabo con una librería de comunicación serie de Java, de la que
no hay demasiada documentación, además de no ser intuitiva y no todas sus
utilidades funcionan correctamente en todos los entornos. Para facilitar aun más las
cosas, se dispondrá de una API que detalle las funcionalidades y operaciones que se
pueden realizar en la red. De esta manera, utilizar esta utilidad a la hora de programar
será tan fácil como pueda ser utilizar cualquier otra librería de Java mientras
programas.
Otra gran ventaja que ofrecerá esta utilidad es el amplio abanico de programas que
permitirá desarrollar, ya que de cara al usuario, las entradas y salidas básicas de
nuestra aplicación podrán recrear en su ordenador el funcionamiento de una
transacción típica Modbus. Esto significa que se podrán realizar desde programas
especializados orientados a un dispositivo Modbus en concreto, hasta programas
orientados a cualquier instrumento Modbus conectado a nuestra red RS485, pasando
por programas de administración de red, o incluso aplicaciones Web como las que
ofrecen empresas como Lantronix1 o Intellicom2 en sus gateways Modbus –
Modbus/TCP.
1
http://www.lantronix.com/
2
http://www.intellicom.se/
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
13
3.2 Desarrollo de aplicaciones Modbus remotas
Una vez justificado el desarrollo de una formula capaz de facilitar el acceso remoto y
la programación de aplicaciones remotas, debemos estudiar en que medida ofrecen
ventajas las aplicaciones remotas para redes y dispositivos Modbus.
o
La más evidente ventaja del acceso remoto, es que no es necesario un
desplazamiento físico hasta donde esté implementada la red, por lo que
inmediatamente se reducirán los costes de transporte y tiempo de todas las
operaciones de mantenimiento o control que se realicen normalmente
sobre la red o sobre un dispositivo.
o
La gestión de sistemas distribuidos se hace más sencilla usando las
tecnologías de Internet disponibles, por lo tanto conseguiremos mejorar
este aspecto.
o
Esta tecnología nos brinda también la posibilidad de mejorar el servicio a
los clientes. Los tiempos de respuesta se reducirán y podrán desarrollarse
nuevos servicios que carecían de sentido en un ámbito meramente local.
o
Por otra parte podremos aprovechar infraestructuras serie y TCP ya
creadas sin necesidad de modificarlas, y continuar ofreciendo conexiones
multipunto.
o
Mediante un Standard de comunicación universal como es TCP/IP y un
protocolo público Modbus, obtenemos una red realmente abierta, para un
intercambio y proceso de datos.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
o
14
Se ofrece la posibilidad de realizar conexiones remotas con equipos de
campo, pero no olvidemos que también se ofrece la posibilidad de realizar
conexiones locales por medio de la LAN (Local Access Network). Es
importante resaltar este aspecto, ya que el mercado de portátiles esta
dejando de incorporar rápida y progresivamente las conexiones serie tipo
RS232, que se venían incluyendo sus productos. La empresa hp
(http://www.hp.com) por ejemplo, ya no ofrece este tipo de conexión en
sus últimos portátiles, y es muy común ver como los últimos modelos de
las principales empresas, ya no implementan este tipo de puertos, que
como hemos visto, son muy necesarios en entornos industriales, en medida
de que la gran mayoría equipos de campo trabajan bajo protocolos serie,
más concretamente, Modbus. Todo esto, e incluyendo la incorporación de
tecnologías inalámbricas de acceso a redes Ethernet (WiFi), convierten
este tipo de aplicaciones, no solo en una solución a la falta de puertos
COM en los portátiles, sino una herramienta cómoda de conexión a redes
Modbus sin necesidad de cables.
Cliente #1 TCP/IP
Servidor TCP/IP
Esclavo #1 Modbus
Maestro Modbus
RS485
Esclavo #2 Modbus
Cliente #2
TCP/IP
Figura 8: Ventajas wireless aplicadas al mundo TCP - Modbus
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
15
3.3 Controlador remoto del CP2003
Dos puntos pueden resumir la motivación a la hora de crear una herramienta que se
comunique con el equipo CP2003 de SACI:
1. Necesidad de ofrecer un servicio: El origen de este proyecto surge de la
necesidad transmitida por el director de obtener un polling remoto de medidas
energéticas, sobre una red eléctrica y utilizando el dispositivo CP2003. Este
será proporcionado por el laboratorio de la Universidad Pontificia Comillas.
Como hemos visto anteriormente, SACI si proporciona una herramienta, bajo
licencia, de manejo de su equipo, pero ésta, además de ser de pago, no
proporcionaría acceso remoto.
2. Necesidad de probar la herramienta de desarrollo: Desde un punto de
vista más personal, esto representa una buena oportunidad para probar la
potencia y sencillez del sistema de desarrollo creado con anterioridad, en una
aplicación con un uso real, pudiendo así implementar las funciones y
utilidades de la API de nuestra herramienta de desarrollo.
Vamos a tratar de exponer un ejemplo típico en el que un control de energía de la red
eléctrica como el que ofrece CP2003 puede ser útil. Supongamos que el propietario
de un hotel está preocupado por el consumo y la calidad de su servicio, y no sabe
cuanto gasto le puede suponer mantener el aire acondicionado en servicio, por
ejemplo, durante los días fríos o de invierno. El dueño del hotel supone que si
mantiene encendido el aire en estas circunstancias, el consumo será menor que
durante el verano o los días calurosos, ya que mucha gente no hará uso de él. Sin
embargo también sabe que mantener encendido este servicio para todo el hotel
supondría un gasto. Sistemas como el CP2003 pueden ayudar a cuantificar esas
suposiciones y ayudar a justificar las decisiones que se tomen. Sin embargo este tipo
de operaciones no se llevarían a cabo si el dueño del hotel tuviera que ir al lugar
donde esta conectado a la red eléctrica el dispositivo y tomar nota de los datos. El
acceso remoto va a facilitar sustancialmente las operaciones administrativas de este
tipo.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
16
4 Identificación de Necesidades
4.1 Objetivos
A partir de este momento nos referiremos como RemModbus, a la herramienta que
se va a crear para permitir y facilitar el desarrollo de aplicaciones Modbus remotas
en Java, y como RemCP2003
4.1.1 Objetivos Generales
Desarrollar una aplicación que facilite el desarrollo de aplicaciones
Modbus sobre Internet o intranet. (RemModus)
Proporcionar acceso remoto a un conjunto de medidas realizadas al
dispositivo CP2003 (RemCP2003).
Desarrollar RemCP2003 utilizando RemModbus.
RemCP200X
RemModbus
Figura 9: Cooperación entre productos finales
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
17
4.1.2 Objetivos de RemModbus
Conseguir la comunicación básica Modbus: intercambio de PDUs.
Permitir, mediante una instanciación muy sencilla, el acceso de cualquier
aplicación Modbus a la red, de forma remota.
Permitir acceso múltiple a la aplicación.
Aplicación escalable.
Diseñar una arquitectura modular que permita incorporar fácilmente
varios dispositivos a la red.
Implementar esa arquitectura y permitir comunicar con varios dispositivos
Desarrollar una API que facilite la utilización de RemModbus.
Trasladar a nuestra aplicación de desarrollo todo el potencial y la sencillez
de la red Modbus que sea posible.
Establecer un control de acceso sobre la red.
Permitir a las implantaciones utilizar distintos niveles de usuario.
Permitir la implementación de un polling de tramas Modbus sobre la red.
Permitir el acceso a los resultados de dicho polling.
Utilidad de búsqueda automática de dispositivos Modbus conectados a la
red.
Ofrecer cierto reconocimiento y recuperación de fallos, necesario para
aplicaciones remotas, y no ofrecido por Modbus. Por ejemplo, solucionar
la colisión que se provocaría si se ejecutan dos peticiones al mismo
tiempo o reponerse ante una situación de no respuesta.
Ofrecer información sobre el estado de la red, o mejor dicho del sistema
que administra la red (RemModbus).
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
18
4.1.3 Objetivos de RemCP2003
Entendamos provisionalmente como RemCP2003 a cualquier aplicación que
haga uso de la red de forma remota y en concreto del CP2003, utilizando
RemModbus.
Creación del programa que permita, instanciando solo una clase, a
cualquier aplicación Modbus ya creada (por ejemplo la ofrecida por SACI
para CP200X), acceder a la red administrada por RemModbus y por tanto
a sus dispositivos de forma totalmente transparente.
Creación de una aplicación Java RemCP2003.
Creación de un Web Service RemCP2003.
Administración de usuarios.
Implementación de competencias según nivel de usuario.
Implementar la comunicación básica “request-response”.
Dar soporte al trabajo sobre varios equipos CP2003.
Administración de polling en función de las necesidades de cada
dispositivo.
Administración del sistema (RemModbus) que maneja la red Modbus, y
por tanto administración de la misma
Implementar la mayor cantidad de recursos disponibles en RemModbus
para conseguir una aplicación sólida y evaluar su potencia y versatilidad.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
19
4.2 Alcance de la aplicación
Se desarrollará en primer lugar la herramienta RemModbus con las funcionalidades
necesarias para dar soporte a los requerimientos de una aplicación remota que
necesita ser desarrollada. En el ámbito de este proyecto esta aplicación es la que
hasta ahora conocemos como RemCP2003.
Dado que uno de los objetivos consiste en probar y evaluar la sencillez, versatilidad y
potencial de RemModbus, se ha decidido dividir la segunda parte del proyecto,
consistente en la utilización de la herramienta (concretamente sobre CP2003) y en
lugar de desarrollar una sola aplicación que haga uso del máximo de funciones
posibles, se van a desarrollar tres tipos de aplicaciones modulares que tendrán
distintos objetivos.
De esta manera vamos a dividir lo que antes conocíamos como RemModbus en tres
aplicaciones modulares:
1. BridgeModbus: Nos va a permitir crear un puente entre un puerto COM
virtual del cliente y la red Modbus a la que nos conectaremos remotamente.
El objetivo de esta aplicación es permitir que cualquier programa ya
desarrollado y preparado para trabajar sólo en ámbito local, pueda hacerlo de
manera remota. Consistirá en la aplicación más sencilla de todas a la hora de
codificar, ya que solo tendremos que instanciar RemModbus y llamar a uno
de sus métodos.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
20
2. RemCP2003: Mantendremos el nombre original para aquella aplicación Java
que permitirá, en función del nivel de usuario, enviar o solo tramas definidas
con anterioridad o además tramas arbitrarias a juicio del usuario.
3. WebCP2003: Para demostrar la flexibilidad de RemModbus, se ha decidido
implementar un Web Service basado en él. Mediante esta herramienta Web
podremos acceder a parámetros de funcionalidad de la red, conocer su estado,
los dispositivos conectados, administrar el polling y administrar usuarios.
Todo ello en función también del nivel de usuario.
4.3 Tipología de los usuarios
A partir de la información recopilada hasta ahora ya se puede perfilar a qué tipos de
usuarios está dirigido este proyecto.
•
Usuarios de empresa: Cualquier usuario que necesite tomar medidas de
energía de una red eléctrica, por ejemplo un gerente para tomar decisiones
administrativas en función del consumo de una planta, o un analista
interesado en estudiar las variaciones de ciertas medidas como voltaje o
intensidad de un entorno eléctrico.
•
Usuarios comunes: Cualquier persona que tenga contratado un plan eléctrico
y sospeche que podría ahorrar más con otro más barato, pero no sabe
realmente cuanta energía utiliza, y por lo tanto no sabe que plan se adapta
mejor a sus necesidades
•
Programadores y desarrolladores industriales o relacionados con el protocolo
Modbus.
•
Usuarios de dispositivos o redes Modbus.
•
Usuarios de CP2003.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
21
4.4 Restricciones
El sistema presenta algunas restricciones importantes, algunos de ellos no a la hora
de desarrollar los productos, pero si a la hora de utilizarlos:
•
RemModbus en su versión Servidor, sólo funciona en Microsoft Windows. El
sistema se ha probado satisfactoriamente en XP SP2 y Vista.
•
BridgeModbus, al utilizar la misma tecnología que RemModbus, sólo
funciona en Microsoft Windows. El sistema se ha probado satisfactoriamente
en XP SP2 y Vista.
•
La base de datos de usuarios debe estar alojada en un servidor MySQL.
•
El servidor MySQL por defecto, se encuentra alojado en de la Universidad de
Westminster, Londres (“jdbc:mysql://rhino.cscs.wmin.ac.uk:3306/3sfe617”,
Usuario: 3sfe617, Contraseña: 3sfe617, nombre de la tabla de usuarios:
w1092467_user).
•
Para un correcto funcionamiento de RemModbus y BridgeModbus, se deben
instalar las librerías de comunicación de Java en las carpetas correspondientes
de la JRE.
•
Las entradas y salidas de RemModbus se efectuarán en forma de
java.lang.String, que comúnmente serán tramas Modbus con el siguiente
formato: 0x01-0x04-0x04-0xb5-0x00-0x01…
•
Dado que los PCs que implementan puertos COM, típicamente funcionan
sobre RS232, si se desea permitir la conexión de varios dispositivos se debe
crear una red RS485. Para ello el laboratorio ofrece convertidores hardware
RS232-RS485.
•
Para la ejecución del Web Service de WebCP2003, se necesitará Apache
Tomcat.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
22
5 Metodología de desarrollo
Método incremental o evolutivo. –
Como hemos venido estableciendo, este proyecto se divide en varias fases. Además y
como la mayoría de los proyectos cada fase se divide a su vez en distintas subfases,
que posiblemente estén formadas por distintas etapas.
Se han estudiado varios métodos existentes para ver cuál es la arquitectura de
metodología que mejor se adapta a la que hemos utilizado para el desarrollo del
proyecto. La que más se aproxima es denominada método incremental o evolutivo,
con el cual “se comienza el desarrollo satisfaciendo un conjunto de requisitos, una
base estable. Las siguientes versiones proveen los requisitos que faltan,
evolucionando el sistema fase a fase” [L01].
Primero se han definido unos principios
mínimos para poder codificar un primer
Fase n
modelo del núcleo del sistema sobre el que
Fase 2
poder trabajar. Posteriormente se ha dividido
Fase 1
en fases el proyecto estableciendo claramente
sus las competencias que debía abordar, y se
ha aplicado este modelo a cada una de esas fases, pudiéndose obtener de cada etapa
un realizar un primer modelo del núcleo del sistema y codificarlo. Esto se adapta
muy bien a nuestras necesidades ya que no teníamos certeza de cómo se desarrollaría
la aplicación, ni cómo íbamos a solucionar ciertos problemas de implantación.
Por otra parte el modelo evolutivo o incremental, se adapta muy bien a la
programación orientada a objetos, y dado que utilizamos Java para su desarrollo,
parece ser de nuevo la mejor opción.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
23
6 Recursos, herramientas y tecnologías empleadas
Para el desarrollo de en Java se ha utilizado
o Java 2 Standard Edition (J2SE) como lenguaje de programación.
o NetBeans IDE 5.5.1 como entorno de programación.
o NetBeans GUI Builder para el desarrollo de interfaces gráficas de
Java.Swing.
o Librería Java javax.comm para las comunicaciones serie.
o NetBeans Java Runtime Environment (JRE) como entorno de
ejecución.
o Notepad++ 4.5 para ediciones puntuales de código.
VSPD XP4, para establecer una conexión entre dos puertos virtuales.
Para el acceso a Bases de Datos (BBDD),
o Servidor MySQL para alojar la BBDD
o MySQL Administrator 1.2.12 para conexión, creación y edición de
tablas e información de mi BBDD
o MySQL Java Connector 5.1.6 para permitir a la aplicación Java
conectarse a la BBDD e interactuar con ella.
Para el diseño y planificación de la aplicación,
o Jude-UML 1.6.2 para la creación de diagramas.
o Microsoft Visio 2002
o Microsoft Project 2002
Para el desarrollo de este documento
o Microsoft Office XP
o Adobe Photoshop CS2 para la edición de gráficos
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
24
Se han utilizado varias tecnologías de comunicaciones
o TCP, Ethernet, 10/100BaseT
o Serie, Modbus, RS485
o Osciloscopio para el estudio de señales RS232 y RS485.
Para la comunicación Serie,
o CP2003
o PLCs y pupitre de mando para proporcionar mas funcionalidad al
CP2003
o Windmill comDebug y Hyperterminal para la captura e interpretación
de tramas Modbus.
Se han utilizado dos convertidores hardware,
o Convertidor USB – Serial
o Convertidor RS232 – RS485
Se ha desarrollado tecnología Web Service basada en Servlet y JSP
o Apache Tomcat para ejecutar el servidor Web
o Adobe Macromedia Dreamweaver CS2 para la edición de las páginas
JSP.
o Notepad++ 4.5 para ediciones puntuales de código.
o Adobe Photoshop CS2 para la creación y edición de imágenes.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
25
7 Estudio de la arquitectura
7.1 RemModbus y RemBridge
Como con toda aplicación Java se va a precisar de un entorno de ejecución tipo JVM
(Java Virtual Machine). También hemos visto en restricciones que estas dos
aplicaciones deben estar montadas sobre Microsoft Windows, debido a que el uso de
los puertos COM de unos sistemas operativos (OS) a otros. Con el fin de orientar el
producto al mayor número de usuarios posible, se ha pensado que era más útil
centrarse en Windows por encima de otros OS como Linux. Es por eso que se ha
decidido utilizar la librería JavaX (Java Standard Extension) Java Communications,
orientada a Windows.
Es necesario disponer de un puerto serie físico en el ordenador que ejecute
RemModbus y de dos puertos virtuales serie conectados entre sí en el ordenador que
ejecute RemBridge. Un convertidor USB-Serial y una aplicación de administración
de puertos virtuales, solucionarían este problema (no se proporcionan).
En caso de querer dar soporte a toda una red de dispositivos Modbus, será necesario
un convertidor de señal RS232-RS485 (proporcionado por la Universidad).
7.2 RemCP2003 y WebCP2003
Será necesario un entorno de ejecución JVM para estas dos aplicaciones. Se precisará
que el ordenador que aloje WebCP2003 no tenga el puerto 3306 bloqueado, ya que
las conexiones a la BBDD se realizan por ese puerto.
Lógicamente, es necesario al menos un CP2003.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Introducción
26
7.3 Arquitectura extendida de la aplicación.
Red
CP2003 #1
Cliente 1
Eléctrica
RS485
Servidor
RemModbus
RS232
CP2003 #2
Convertidor
RS232/RS485
Router
RS485
10/100BaseT
TCP/IP
Dispositivo
Modbus
Cliente 4
Cliente 2
WebCP2003
RemCP2003
Usando
Cliente 3
RemModbus
Figura 10: Diseño ampliado de la arquitectura
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
27
Capítulo 2 REMMODBUS
1 Introducción
En este capítulo tiene como propósito centrarse en el diseño, fases y programación de
RemModbus, ya que a partir de este punto las dos partes del proyecto dejan de tener
los suficientes elementos comunes como para ser tratadas por igual.
Como esta aplicación trabajará sobre una red Modbus es interesante concretar un
aspecto de Modbus que no se mencionó con anterioridad y que hay que tener en
cuenta a la hora de diseñar. Existen dos variantes, con diferentes representaciones
numéricas de los datos y pequeñas diferencias en el control de trama. “Modbus RTU
es una representación binaria compacta de los datos mientras que Modbus ASCII es
una representación legible del protocolo pero menos eficiente” [19]. Ambas
implementaciones del protocolo son serie. El formato RTU finaliza la trama con un
suma de Control de Redundancia Cíclica (CRC, 2 Bytes), sin embargo en ASCII se
añade un carácter de encabezamiento («:» = 0x3A) y los caracteres CR y LF
(Carriage Return y Line Feed, 0x0D0A, que al trabajar con Big Endian de 16 bits se
traduce en dos campos de dos Bytes: 0x0D 0x0A) a continuación del PDU. La trama
ASCII se finaliza con una suma de Control de Redundancia Longitudinal (LRC, 1
Byte).
‘:‘ (0x3A)
ID
CMD
INFO (PDU)
CR
LF
LRC
Figura 11: Trama Modbus ASCII
Dado que el formato utilizado por SACI para CP2003 es el RTU y ademas es el más
extendido, las aplicaciones se han orientado a este tipo de formato, por lo que NO se
permite la comunicación Modbus ASCII en este proyecto
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
28
2 Diseño
RemModbus va a estar dividido en dos subprogramas, que funcionarán bajo una
arquitectura Cliente/Servidor que se comunicarán entre ellos mediante un protocolo
propio diseñado expresamente para RemModbus.
El programa Servidor se encargará principalmente de recibir y validar las conexiones
entrantes, así como de la transmisión serie de tramas y la administración del estado
de la red. Recordemos que el protocolo Modbus es un protocolo sin estados ni nivel
de transporte. Esta aplicación nos va a permitir establecer ciertos principios de
control y estado.
El programa Cliente, de cara al usuario, consistirá en una clase a instanciar que
permita la utilización y el acceso a la información ofrecida por el Servidor, mediante
el uso de sus métodos y de forma totalmente transparente al usuario, en función de
las necesidades del usuario.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
29
2.1 Diseño de la Base de Datos
Como veremos a continuación no se precisa una lógica muy desarrollada para el
diseño de este apartado ya que tan solo necesitaremos una tabla en la que podamos
albergar un conjunto de usuarios, sus contraseñas, y el nivel que tienen. No obstante
se especificará aquí por si se requieren modificaciones posteriores.
Diseño lógico de la Base de Datos
•
w1092467_user
(NAME, PASS, PERMISSION)
El nombre de la tabla está adecuado a las normas de la Universidad de Westminster.
NAME
Será el alias del usuario. Se definirá como clave primaria.
PASS
Guardará la contraseña del usuario.
PERMISSION
Nivel del usuario. A discreción de los programadores finales
Definición SQL de las tablas
CREATE TABLE w1092467_user (
NAME
VARCHAR (20) NOT NULL,
PASS
VARCHAR (20) NOT NULL,
PERMISSION
VARCHAR (20),
PRIMARY KEY (NAME);
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
30
2.2 Diseño del protocolo RemModbus
Se ha diseñado un protocolo que se adapte perfectamente a las necesidades de
comunicación entre los programas Cliente y Servidor del paquete RemModbus. Esta
comunicación comúnmente se iniciará por parte del cliente, que requerirá algún tipo
de acción por parte del servidor.
1. Trama de acción
3. Trama de confirmación
2. Proceso
Cliente
Servidor
Figura 12: Protocolo RemModbus
En el ejemplo vemos como un cliente envía una trama RemModbus al servidor
pidiéndole algún tipo de acción. Esta acción puede consistir desde un proceso
complicado como el de conexión hasta una consulta puntual de un estado concreto de
la red, o por supuesto una transmisión de una trama Modbus.
CABECERA
DATOS
LONGITUD
Figura 13: Trama RemModbus
A continuación estudiaremos el diseño y la funcionalidad de las tramas RemModbus.
El protocolo esta diseñado para que cada trama enviada, reciba al menos una trama
de respuesta por parte del receptor de la trama, ya sea para indicar que la operación
ha tenido éxito o para notificar del error. Esto nos ofrece la información necesaria
para tener la posibilidad de implementar un sistema de detección y recuperación de
errores donde antes no se podía.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
31
Se permitirán cuatro tipos distintos de operación en el servidor, en función del valor
de “CABECERA”, que tendrá un tamaño de 4 Bytes. Si es de tipo:
i.
CON, se estará iniciando un proceso de conexión.
ii.
SYN, se esta enviando o solicitando información al servidor para
mantener sincronizados tanto a cliente como a servidor. Las distintas
subclases de las tramas de sincronización se abordarán en la parte de
programación de este mismo capítulo
iii.
DAT, la información del campo de DATOS será normalmente una
trama Modbus, que tendrá como finalidad ser transmitida en la red de
destino.
iv.
DAO, estamos hablando de un intento de acceso a la BBDD para
consulta o modificación de usuarios.
Los valores comunes a cliente y servidor son todas aquellas tramas cuya cabecera sea
de tipo:
v.
ACK, o cualquiera de sus variantes: NACK. ACK_DAT, etc.
El campo “LONGITUD” de 4 Bytes, como su propio nombre indica nos va a
permitir saber hasta donde tenemos que leer para obtener el resto de la trama. Esto
significa que vamos a poder enviar en el campo de “DATOS” hasta 2 32 − 1 Bytes, lo
cual cubre de sobra nuestras necesidades.
Finalmente el campo “DATOS” contendrá la información necesaria para la
operación que se precise, ya sea en la parte del servidor como en la parte del cliente.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
32
2.2.1 Proceso de conexión y establecimiento de usuario:
Intercambio de tramas. Formato:
CLIENTE
CABECERA (DATOS)
(acción)
SERVIDOR
(acción)
1. CON (usuario + contraseña)
0. Establecer conexión sobre
puerto de escucha
0. Escuchando en el puerto de
escucha “well known”
2. Validación de usuario.
4. ACK_CON (puerto + nivel de usuario)
3. Cálculo de Puerto
5. Se termina la conexión con
el cliente del puerto well known
5. Establecer escucha en el
puerto recibido
6. Escuchando en dicho puerto
4. ACK_DAT (puerto + nivel de usuario)
6. Primer envío de información:
Lista de dispositivos
conectados.
Figura 14: Establecimiento de conexión en el protocolo RemModbus
Para implementar un sistema que permita la conexión simultánea de varios usuarios a
la red se ha optado por un sistema en el cual a cada conexión se le establece un
puerto en el servidor, que además nos servirá de identificador. Para resolver el
problema de cómo sabe el cliente que puertos están libres en el servidor, utilizamos
una pequeña modificación en el concepto de la conexión: el cliente inicia una
conexión sobre un puerto well known (conocido de antemano) del servidor, sobre el
que tiene la certeza que esta escuchando. A continuación el servidor, tras hacer las
validaciones oportunas de usuario (conexión a la BBDD y comprobar si es correcto),
si todo ha funcionado bien, enviará una trama ACK_CON con el puerto asignado a la
conexión, y el nivel del usuario validado, obtenido de la base de datos. Es decir, se
cerrará la conexión sobre el puerto de escucha, y será el servidor el que inicie la
conexión sobre el cliente. En caso de que la validación de usuario no sea positiva, se
enviará una trama NACK, y no se seguiría con el proceso. Posteriormente el servidor
volverá a enviar una trama por la nueva conexión. La trama será en este caso de tipo
ACK_DAT y contendrá la última actualización de la lista de dispositivos conectados.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
33
2.2.2 Otras transacciones cliente – servidor. Lógica de confirmaciones.
Después de comprender el funcionamiento de la lógica de conexión se puede pensar
que el protocolo es complejo y poco amigable a la hora de trabajar con el. Sin
embargo, el protocolo no solo es fácil de entender como veremos ahora, sino que
también es fácil de programar y utilizar, como veremos mas adelante.
Toda la lista de transacciones que veremos más adelante sigue siempre la misma
lógica, basada en la trama de confirmación recibida.
1. CAB (DATOS)
0. Realizar operación de tipo
CAB en el Servidor
1. ACK_CAB (void)
2. Procesar operación de tipo
CAB en el Servidor
1. CAB (DATOS)
0. Realizar operación de tipo
CAB en el Servidor
1. ACK_DAT (DATOS)
2. Procesar operación de tipo
CAB en el Servidor
1. CAB (DATOS)
0. Realizar operación de tipo
CAB en el Servidor
3. NACK (void) o NACK_DAT (DATOS)
2. Procesar operación de tipo
CAB en el Servidor
Figura 15: Lógica de confirmaciones del protocolo RemModbus
Si la operación en el servidor ha sido satisfactoria, se enviará una trama de
confirmación ACK_CAB (donde CAB es el tipo de trama enviada originalmente) en
caso de que no se necesite información adicional o ACK_DAT, en caso contrario. Si
la operación no ha podido llevarse a cabo por alguna razón, se transmite una trama
de tipo NACK, o NACK_DAT, siguiendo la misma lógica.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
34
2.2.3 Lista de transacciones
Tipo CON: (transacción vista con anterioridad)
CON + Usuario y Contraseña.
ACK_CON + Puerto
Tipo SYN:
SYN_POLON :
Arranca o detiene el polling. Devuelve el estado.
SYN_POL:
Devuelve en que estado se encuentra el polling.
SYN_POLDAT + lista polling:
Actualiza la lista de polling en el server.
SYN_CON:
Desconecta al usuario del puerto de la conexión.
SYN_FIN:
Devuelve la última revisión de los dispositivos conectados.
SYN_FINON:
Arranca el proceso de búsqueda de dispositivos. Devuelve el tiempo estimado
para la finalización del proceso.
SYN_CAN:
Permite al usuario renunciar a la siguiente trama que fuera a recibir.
SYN_ETA:
Devuelve el tiempo estimado para que el servidor se quede sin ninguna
ocupación, o NACK si ya está libre.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
35
Tipo DAT:
DAT + trama:
Envía a la red Modbus trama, y devuelve la respuesta de la red. Mediante
esta trama si el servidor esta ocupado atendiendo alguna labor administrativa
como la búsqueda de dispositivos, se cancela el envío a la red Modbus y se
devuelve NACK + ETA (Estimated Time of Arrival).
DAT_ABS: + trama:
Funciona de la misma forma que DAT a excepción de que si hay un proceso
funcionando, la petición se encola y el cliente debe esperar su turno. Una vez
enviada la trama no se puede cancelar la ejecución de la trama.
Tipo DAO:
DAO_UPD + nombre, campo a cambiar y nuevo valor del campo:
Nos permite editar el valor del campo indicado, del nombre de usuario.
DAO_DEL + nombre:
Nos permite eliminar el usuario indicado.
DAO_ADD + nombre, contraseña y nivel de usuario:
Crea un usuario con los parámetros indicados.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
36
2.3 Diseño de RemModbus Servidor
Esta versión del paquete RemModbus hará de representante del dispositivo maestro
que desee interactuar con la aplicación. Debe ser instalada en un ordenador
conectado a la red Modbus, normalmente mediante RS232. Para el uso de varios
dispositivos dentro de la red se recomienda utilizar un convertidor de señal RS232RS485 como los que ofrece el laboratorio de la universidad. La aplicación tiene tres
partes muy bien diferenciadas, la primera, de acceso a los puertos serie del
ordenador, y a la información que se transmita o reciba de ellos, y la segunda, de
procesamiento de conexiones entrantes, y una última que interprete las ordenes se
reciban de los clientes conectados.
2.3.1 Lógica del enlace físico con los puertos del protocolo Serie.
Diagrama 1: Enlace a puertos serie
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
37
2.3.2 Lógica de conexión de equipos remotos
Diagrama 2: Procesador de conexiones entrantes
2.3.3 Diseño de control de estado de la red.
Para implementar un sistema de control de estado, que permita conocer en todo
momento detalles concretos de la red, se va a crear una clase que albergue todo este
tipo de información. Adelantamos que el nombre de esta clase va a ser Estado.java.
Es imperativo para el correcto funcionamiento de la aplicación que esta clase se
mantenga actualizada en todo momento, ya que será de alguna manera la base de
datos de la red, y la referencia a la que acudirán otros procesos y programas para
realizar sus operaciones. A partir de ahora conviene distinguir entre conexión o uso
de la red (Modbus), que será interpretado como uso físico del RS232 o RS485 y
conexión y uso del sistema, entendiendo por sistema ‘RemModbus’. Empecemos por
establecer a continuación cuales serán las competencias de esta clase.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
38
Acceso a la red Modbus.
o Que
tipo
de
proceso
esta
utilizando
la
red
actualmente
(transmitiendo), si es que se da el caso. Entendemos por tipo de
proceso, un usuario accediendo a la red, el proceso de polling, o el
proceso de descubrimiento de dispositivos.
Administración del polling. Saber en todo momento si,
o Hay intención de hacer polling, aunque no se este ejecutando porque
este otro proceso ejecutándose.
o El polling se está ejecutando.
o Cual es la lista de tramas que lo conforma
o Cuales son las respuestas obtenidas a esa lista de tramas
Administración de usuarios. Saber en todo momento,
o Que usuarios están conectados y a través de que puerto.
o Cuales de ellos desean transmitir.
o Ofrecer desconexión.
Administración de cola de acceso a la red Modbus. Hay que considerar,
o No todos los dispositivos pueden transmitir. Hay que desarrollar un
método de acceso a la red.
o Ofrecer métodos para sumarse a la cola.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
39
Administración de los dispositivos conectados
o Ofrecer un sistema común para todos los dispositivos Modbus que
permita el descubrimiento de los dispositivos de la red.
o Estado de dicho sistema. Si está en marcha o no.
o Que dispositivos están conectados.
o Tiempo estimado para que termine el proceso de finding
(descubrimiento)
o Posibilidad de introducir manualmente los dispositivos
Información y actividades relacionadas con el enlace a la red Modbus.
o Obtención de canales físicos de transmisión.
o Métodos de transmisión y recepción de tramas.
Control de los tiempos de respuesta de tramas a una request sobre un equipo.
o Utilizado para deducir si la red ha contestado a una determinada
trama.
Estado de la conexión TCP/IP y Modbus
o Está el sistema conectado a la red o no.
o Está el sistema escuchando en el puerto de escucha o no.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
40
2.3.4 Lógica de colas.
Como Modbus no ofrece mecanismo control de envío, ni de acceso a la red, ni de
recuperación y retransmisión de tramas, tenemos que buscar una solución para evitar
el problema que se plantea ante la situación en la que se transmitan varias tramas al
mismo tiempo, o antes de que el primer emisor haya recibido su respuesta.
Intentaremos representar el problema real de cualquier red Modbus con varios
maestros accediendo simultáneamente, con un ejemplo.
Usuario #1
Dispositivo #1
RS485
Usuario #2
Dispositivo #2
Figura 16: Red Modbus
Hipótesis: El usuario #1 (u1) transmite una trama 0x01-0x01-0x01 a la que en
condiciones normales el
dispositivo #1 (d1) contestaría 0x11-0x11-0x11. De la
misma forma el usuario #2 (u2) transmite una trama 0x02-0x02-0x02 a la que en
condiciones normales el dispositivo #2 (d2) contestaría 0x22-0x22-0x22.
[1] Supongamos que u1 transmite e inmediatamente lo hace u2. De cara a d1 y d2
se recibiría una sola trama formada por una mezcla aleatoria de los bits de la trama
de u1 y de la trama de u2, por lo que aunque los dos dispositivos recibirán la trama
ninguno sabrá procesarla y no se obtendrá respuesta.
[2] Supongamos que u1 transmite y d1 reconoce la trama. Mientras u2 ha
transmitido y su trama llega a d2 justo después de que d1 reconociera la trama, con lo
que d2 también la reconoce. Por lo tanto tenemos otra colisión formada por las
respuestas, por ejemplo 0x11-0x22-0x11-0x11-0x22-0x22. Los usuarios no podrán
interpretar la respuesta. Además ¿quién recibe la trama? ¿u1, u2, los dos o ninguno?
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
41
Además se puede dar la posibilidad de antes de que u1 reciba la respuesta de d1 y
éste ya haya contestado, u2 transmita. Recordemos que RS232 es un medio halfduplex (la información puede viajar en un sentido o en otro, pero no al mismo
tiempo) por lo que debemos evitar esta situación en la solución que ofrezcamos, y
hacer que la red Modbus completa (incluyendo RS485) funcione en modo halfduplex.
Si recordamos el aspecto de nuestra arquitectura y la enfrentamos a una típica como
la del ejemplo anterior vemos que la principal diferencia reside en que nuestra
arquitectura provee a la red Modbus de un solo dispositivo maestro real
(RemModbus) al que se conectan los maestros potenciales. Esto nos va a permitir
crear un cuello de botella para administrar quién entra a la red en cada momento.
Requerimientos funcionales para el acceso a colas:
R01 – Para conexiones modulares de usuario, que constan de un input y un output,
se utilizara un sistema FIFO (First In First Out)
R02 – Toda transmisión modular ya transmitida debe terminar su ejecución y
esperar a la respuesta de la red.
R03 – El proceso de descubrimiento de dispositivos, se considera una acción de
actualización del sistema, que debe ejecutarse antes que cualquier proceso
que esté en la cola.
R04 – Cualquier proceso tiene una prioridad mayor que el polling. Es decir, el
polling solo se ejecutará si no hay nada que precise ejecutarse.
A continuación veremos su aplicación en los métodos que acceden a la red:
Comunicación Modbus, Descubrimiento de dispositivos y Polling
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
42
2.3.5 Lógica de la comunicación Modbus.
Diagrama 3: Comunicación Modbus
Recordemos que cada trama Modbus transmitida obtiene una o ninguna respuesta en
función de si ha sido reconocida y aceptada por el equipo Modbus o no. Este
diagrama muestra también la implicación del cliente, desde la recepción de una trama
DAT enviada por él, hasta el envío de la respuesta obtenida de la red. Nótese además
la implantación de la lógica de la diferencia entre DAT y DAT_ABS explicada con
anterioridad. Hay que destacar también la implicación del sistema de colas para el
usuario, recordemos, FIFO.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
43
2.3.6 Diseño de control de obtención de respuestas.
Estudiando el diagrama anterior observamos que la finalización de la aplicación,
depende de que la red conteste a la trama, pues el programa quedaría bloqueado en
“Recibir trama” hasta que haya respuesta. Esto se debe a la implementación de otro
sistema de control de la red que se ha implantado. El objetivo es que si al cabo de un
cierto tiempo no se ha leído la trama, supongamos que hubo un error y actuemos en
consecuencia. Esto se conseguirá imponiendo un timeout a la instrucción de lectura.
Diagrama 4: Timeout
Vemos que en caso de no recibir nada, creamos una trama ficticia con el valor
binario ‘0’, aquí representado en hexadecimal 0x00.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
44
2.3.7 Lógica del descubrimiento de dispositivos conectados a la red (Finding).
Vamos a definir el proceso de finding como una actualización de estado, para el
correcto funcionamiento del sistema, por lo que es se supone que si se ha ejecutado,
es porque se sospecha que la lista de dispositivos del sistema ha quedado obsoleta.
Por tanto vamos a establecer el siguiente requisito funcional:
R05 – El proceso de descubrimiento de dispositivos no puede ser interrumpido por
ningún usuario o proceso hasta su correcta terminación.
Diagrama 5: Finding
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
45
2.3.8 Lógica del polling.
A diferencia del finding, el este proceso si que puede ser detenido o interrumpido. De
hecho no tiene sentido que no lo sea, ya que es un proceso infinito por definición. La
solución que se ha adoptado para permitir este tipo de ejecuciones en nuestro
sistema, es aceptar listas de tramas del usuario, y establecer si se ejecutan o no. De la
misma forma que se reciben las listas de tramas, se ofrecerá la posibilidad de
recuperar una lista con las respuestas obtenidas a esas tramas, por lo que es muy
importante mantener un control sobre qué trama request obtiene qué trama response.
Como es lógico cualquier transacción o proceso se ejecutará antes que cualquier
transacción de polling respetando R04. Además añadimos otro requisito funcional,
que se antoja evidente, pero que hay que tener en cuenta a la hora de programar.
R06 – El proceso de polling que es detenido por otro proceso o transacción, debe ser
reactivado al terminar dicho proceso o transacción.
Diagrama 6: Polling
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
46
2.3.9 Lógica de transmisión de tramas. CRC.
Hemos visto como generábamos un cuello de botella para el acceso a la red y luego
invocábamos al envío y recepción de tramas. Hay que recordar que estamos
utilizando una modalidad de Modbus llamada RTU, cuya peculiaridad es que termina
sus tramas con una suma de control de redundancia cíclica. Se ha de desarrollar una
función que calcule y añada este CRC al final de cada trama. Esta función debe de
estar preparada para el formato de datos utilizado por el sistema. Además hay que
tener en cuenta que no consiste en un típico CRC de 32 bits, sino que es de 16 bits.
Diagrama 7: Cálculo del CRC
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
47
2.4 Diseño de RemModbus Cliente
El objetivo del cliente se concentra en conectarse a la aplicación servidor de
RemModbus y hacer uso de sus funciones a través del protocolo RemModbus
detallado con anterioridad. Esta aplicación deberá ser instanciada por otra aplicación
Java en el ordenador cliente que desea utilizar los servicios de la red que administra
RemModbus. Por lo tanto ha de ser codificada de tal forma que su instanciación
resulte lo más sencillo posible para el programador. Hay que señalar que
RemModbus no tiene en cuenta el nivel de usuario a la hora de ejecutar operaciones,
ya que considera que es competencia de los programas que utilicen sus servicios.
Mediante su instanciación se debe poder permitir
Establecer una comunicación Modbus. Consultar el protocolo Modbus para
ver los distintos tipos de comunicación (operaciones DAT)
Obtener los datos del usuario, sobre todo el nivel de usuario para poder
permitir actuar en consecuencia al programador.
Obtener los equipos conectados de forma pasiva (sin forzar actualización).
Obtener los equipos conectados de forma activa (forzar actualización).
Actualizar las tramas de polling en el servidor.
Obtener resultados del polling.
Obtener tramas de polling actuales del servidor.
Ejecutar y detener polling y/o obtener su estado.
Ejecutar finding y/o obtener su estado. Obtener ETA en caso de que este
funcionando el proceso.
Establecer un puente entre un puerto COM del usuario y la aplicación.
Desconexión del usuario.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
48
3 Programación y pruebas
Antes de comenzar a programar necesitamos instalar las librerías a utilizar:
javax.comm consta de tres archivos. Instalar en las rutas especificadas.
- win32com.dll: guardarlo en la carpeta ..\Java\jdk\jre\bin
- javax.comm.properties: copiarlo en la carpeta ..\Java\jdk\jre\lib
- comm.jar: copiarlo en la carpeta ..\Java\jdk\jre\lib\ext
La instalación suele dar problemas en función de a donde está apuntando
realmente la JRE o la JDK, y de cuál de ellas se está utilizando para la
ejecución. Se recomienda consultar la FAQ de la API de comunicaciones de
Java [20]. Esta instalación será obligatoria para el equipo que desee utilizar
tanto la versión servidor de RemModbus como mas adelante veremos,
RemModbus.
mysql_connector también será utilizado por el servidor RemModbus.
Importar los paquetes necesarios.
Diagrama 8: Organización de RemModbus
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
-
49
pfc_dsm.RemModbus.Inet contendrá las herramientas necesarias para
el protocolo RemModbus, por lo que deberá ser importado por cliente
y servidor, puesto que ambos utilizan sus servicios.
-
pfc_dsm.RemModbus.DAO incluye la lógica de las conexiones a la
BBDD. Puesto que sólo el servidor hace uso de operaciones de este
tipo, será el único que precise importarlas.
-
pfc_dsm.RemModbus.Modbus sirve para acceder al protocolo serie y
establecer un enlace con él. Debe ser importado por el servidor en
cualquier caso y por el cliente cuando necesite crear un puente virtual.
-
pfc_dsm.RemModbus.Utilidades
deben
seguirse
las
mismas
directrices que para pfc_dsm.RemModbus.Modbus.
A pesar de que la API de javax.comm ofrece un sistema de eventos para la recepción
y envío de datos a través del puerto serie, se ha descubierto que no funcionaba
correctamente en algunos casos puntuales, necesarios para desarrollar la aplicación
como estaba disñado. Es por eso que han tenido que ampliarse ligeramente las
competencias de la clase Estado.java y bloquear los procesos con bucles en lugar de
con eventos. Sin embargo el resultado ha sido satisfactorio.
Durante este capítulo se explicarán únicamente la finalidad o funcionamiento de las
funciones o métodos que, o bien no tengan un nombre intuitivo, o bien su desarrollo
a la hora de programar tenga algún aspecto interesante. Tampoco se incluirán todas
los métodos en los diagramas o en los apartados.
Se ha tomado la decisión de estandarizar cualquier proceso de intercambio de datos
entre programas y procesos, independientemente de cómo trabajen internamente.
Además se ha optado porque el intercambio de tramas Modbus sea el interpretado
generalmente para estas redes. Es decir como suelen utilizarse lógicamente los datos
de una trama Modbus.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
50
Requisitos no funcionales
NF01 – Las comunicaciones entre programas y procesos se realizaran por medio
de cadenas de caracteres, enviándolas y recibiéndolas como objetos
java.lang.String.
NF02 – Elementos de una lista se enviarán separados por el carácter ‘&’ o por el
juego de caracteres ‘---‘ en el caso de la conexión.
NF03 – Las tramas serán enviadas y recibidas en todo el entorno RemModbus
como agrupaciones
de 16 bits
e interpretadas
como números
hexadecimales con el siguiente formato: 0xAA donde AA representa el
valor hexadecimal.
NF04 – Cada una de estas agrupaciones se separará de la siguiente mediante el
carácter ‘-‘.
NF05 – La lógica de separación de NF04 se hará extensible a cualquier juego de
elementos de una misma entidad lógica.
NF06 – La aplicación se desarrollara en J2SE.
NF07 – Se usará MySQL para el almacenamiento.
Localizado en rhino.cscs.wmin.ac.uk/3sfe617
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
51
3.1 Programación del acceso a la BBDD
3.1.1 Diagrama de clases
Diagrama 9: Conexión a la base de datos
Se ha decido crear, una clase abstracta DAO que se encargue de almacenar la
información relativa a la BBDD y otra clase que herede de ella, que se ocupe de las
labores administrativas de la base de datos como puede ser
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
52
3.2 Programación del protocolo RemModbus
Para la utilización del protocolo se van a utilizar las herramientas que se han
desarrollado para esta parte del proyecto. Estas están alojadas en el paquete Inet
[Diagrama 8: Organización de RemModbus], que consiste en tres clases:
TramaInet.java, TramaInetIS.java y TramaInetOS.java.
3.3.1 TramaInet.java
Nos dará la oportunidad de instanciar las tramas para acceder fácilmente a sus
campos. A continuación se muestra la parte del código que codifica el tipo de tramas
y el diagrama de clase correspondiente.
public static final int CON
= 29;
public static final int ACK_CON
= 19;
public static final int ACK_DAT
= 39;
public static final int DAT
= 2;
//+trama Modbus. Con finding devuelve ETA
public static final int DAT_ABS
= 1;
//+trama Modbus. Se trans. tb con finding
public static final int SYN_POLON
= 49;
//Pregunta el estado del polling
public static final int SYN_POLRUN
= 48;
//StartStop polling de forma remota
public static final int SYN_FIN
= 46;
//pide la lista de ids
public static final int SYN_FINON
= 44;
//Start finding de forma remota
public static final int SYN_POLDAT
= 47;
//En DAT va la lista de polling
public static final int SYN_POL
= 45;
//pide la lista de poll
public static final int SYN_CON
= 41;
//desconecta al user (logout)
public static final int SYN_CAN
= 42;
//renuncia a la sig.trama respuesta
public static final int SYN_ETA
= 43;
//pide ETA
public static final int ACK_SYN
= 59;
//Ready+lista polling actual u otro
public static final int NACK
= 90;
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
53
public static final int NACK_DAT
= 99;
public static final int MAXDATA
= Integer.MAX_VALUE;
protected int tipo;
//almacena el tipo de trama. uno de los de arriba
protected byte[] datos; //el campo INFO del protocolo Modbus
protected int longitud; //hasta donde hay que leer.
Organización de métodos:
Diagrama 10: TramaInet
Cabe destacar la posibilidad de obtener el campo de datos como String o como
byte[].
3.3.2 TramaInetIS.java y TramaInetOS.java
Diagrama 11: TramaInetIn y TramaInetOS
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
54
Estas dos clases nos van a permitir establecer los canales por los que vamos a enviar
y recibir la información proveniente del protocolo RemModbus.
Gracias a este paquete, nos va a resultar muy sencilla la comunicación con el
protocolo Modbus. Lo primero que debemos hacer es crear los TramaInetIS y
TramaInetOut de la forma siguiente
Socket in = new Socket(…)
//creación de canales tis y tos (entrada y salida)
TramaInetIS tis = new TramaInetIS(in.getInputStream());
TramaInetOS tos = new TramaInetOS(in.getOutputStream());
Una vez creados los canales, cada vez que se quiera recibir o enviar una trama, solo
habrá que hacer uso de los métodos correspondientes. Respectivamente:
//Ejemplo de lectura de trama RemModbus
TramaInet trama = tis.readTramaInet();
//Ejemplo de escritura de trama RemModbus
tos.writeTramaInet(new TramaInet(TramaInet.NACK_DAT, “0x00-0x00”));
//En caso de querer ver que tipo de trama sigue sin leerla realmente:
int tipoSiguienteTrama = tis.siguienteTipoTramaInet();
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
55
3.3 Programación de RemModbus Servidor
El servidor RemModbus tendrá un aspecto similar al siguiente [Figura 17], desde el
que inicialmente podremos en primer lugar, conectarnos a la red Modbus o a la red
TCP/IP. En términos de programación se refiere a crear un nuevo Enlace.java y un
nuevo Server.java. También podremos ejecutar el polling o el finding. También
podremos falsear el proceso de finding si conocemos de antemano las direcciones de
los dispositivos conectados3.
Figura 17: RemModbus Servidor
3
No se ha implementado ningún mecanismo de detección de errores de formato por lo que hay que
tener cuidado a la hora de insertar las direcciones o el sistema se comportara de forma errática.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
56
3.3.1 Programación de gestión conexión con protocolo serie: Enlace.java
Diagrama 12: Enlace.java
Se solicita información del usuario, para establecer los parámetros de conexión a la
red serie. Los parámetros pedidos son tales como puerto COM al que desea
conectarse, velocidad de transmisión, bits de parada, control de flujo, bits de parada,
etc. A continuación creará la conexión4 utilizando la API javax.comm y establecerá
los canales de entrada y de salida típicos.
3.3.2 Programación de gestión de conexiones remotas
3.3.2.1 Server.java
Se encargara de recibir las conexiones entrantes, decidir si son o no aceptadas
y arrancar un servidor personalizado para cada conexión aceptada.
Diagrama 13 Server.java
4
Al crearse una conexión serie, el puerto queda bloqueado no permitiéndose más conexiones sobre él
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
57
El servidor de conexiones entrantes está montado sobre un Thread, bloqueado
dentro de un bucle infinito en la instrucción 3
1 int listeningPort = 9999
2 ServerSocket hall = new ServerSocket(listeningPort,10);
3 Socket in = hall.accept();
Vemos que Server escucha siempre en el puerto well known ‘9999’. Una vez
validado el acceso, se calculara un puerto en el rango [8000 – 8030], en
función de los puertos que se estén utilizando. Esto significa que solo
aceptaremos hasta 30 conexiones remotas. Si se llega al límite se envía una
IOException. Con ese puerto calculado y la dirección IP del cliente, creamos
una nueva ServerSession
3.3.2.2 ServerSesion.java
Diagrama 14. ServerSession.java
El constructor de ServerSession es el encargado real de crear la nueva
conexión. Una vez creada, envía de acuerdo al protocolo RemModbus la
trama de dispositivos conectados. Se arranca el Thread, que queda bloqueado
de la misma manera que Server.java. A partir de este punto recibe las tramas
del protocolo RemModbus, y actúa en consecuencia tras interpretar el tipo de
trama. Típicamente llamara a una función u otra mandando en caso de ser
necesario, una modificación sobre Estado.java.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
58
3.3.3 Programación de gestión de estado: Estado.java
Dada la importancia de esta clase se va a proceder a mostrar todas las definiciones de
atributos. Habrá una y solo una instanciación de esta clase, que debe estar presente
en todas las instancias que efectúen una modificación de estado5. Aprovechando esta
situación se añadirán los métodos necesarios para la transmisión de tramas al puesto
serie.
public static final int POLLING = 991;
//Para determinar quien
public static final int GETDIRECCIONES = 992;
//esta accediendo a la
public static final int ACCESOMAESTRO = 993;
//red Modbus actualmente
private int acceso;
//(sobre acceso)
private boolean onTCP;
//indica si esta conectado a red TCP
private boolean onModbus;
//indica si esta conectado a red MDBS
//polling\\
private boolean polling = false;
//TRUE si hay intencion de polling.
private ArrayList pollingList;
//Ristra de tramas de pregunta poll
private ArrayList pollingListRespone;// ” de tramas de respuesta polling
//formato: "0x01-0x02-0xa3...." los 2 a.l. como manda los NF
private ArrayList accessQueue;
//el turno para varios users, etc
private ArrayList usList;
//Lista de los usuarios conectados
private User currentUserModbus;
//Mantener user en poder del acceso.
private ArrayList modbusId;
//Lista de disp Modbus conectados
//Se guardan sin 0x
5
Es completamente necesario que cualquier modificación en el estado de la aplicación, se vea
reflejado en la instancia única de Estado.java.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
59
private boolean findingDone = true;
//Cuando esta parado el finding
private int findingProgress;
//porcentaje completado finding
private Enlace link;
//via de comunicación con MODBUS.
private Thread cuenta;
//Modifican la variable que dice si
private Timeout to;
//la red responde o no a la trama
private boolean timeOver = true;
//Control de respuesta a trama
private boolean readingModbus = false;//control de lectura del COM;
private boolean tramaOutReady = false;// se ha leido 1 trama completa?
private Trama tramaToSend, tramaReceived;
private Polling poll;
//Polling
private Thread pllng;
private boolean pollRunned = false;//true si se ejecuto una vez
//para no rehacer la inic y tener 2
private UserDAO udao;
//para acceder a los datos de users
Puesto que esta clase implementa más de 50 métodos, vamos a pasar a explicar sólo
una de ellas a modo de ejemplo de uso de Estado.java
public void setFindingProgress(int i){
findingProgress = i;
}
public int getFindingETA(){
return (((255-findingProgress)*to.getTimeout())/100); //en segundos
}
private int getFindingProgress(){
return (((findingProgress + 1)*100)/255);
}
Este ejemplo concreto se permite obtener el tiempo estimado que tardará el finding
en terminar de ejecutarse. Este proceso va actualizando el valor de findingProgress,
así al pedir el progreso o el ETA del finding obtendremos un valor actualizado.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
60
3.3.4 Programación de colas
Este proceso se basa en la misma forma de proceder que en el ejemplo anterior de
petición de progreso y ETA del finding. Los procesos que quieren transmitir, se
añaden en una posición determinada de una cola como se vio en el apartado de
diseño. Los procesos que optarán a transmitir son una comunicación modular
Modbus iniciada por el usuario, o un proceso de polling o finding.
- Proceso de polling. Para cada trama que quiera enviar,
while( !estado.getPollingIntention()
|| estado.getAcceso() != Estado.POLLING
|| !estado.getQueue().isEmpty())
{/*NO HACER NADA*/ try{Thread.sleep(500);}catch(Exception e){}}
//estado.setAcceso(Estado.POLLING);
//estado.setPollingOn(true);
estado.addUserToQueue(u);
//LOGICA POLLING + ENVIO
estado.leaveQueue();
- Comunicación modular (request-response)
estado.addUserToQueue(usuario);
estado.setAcceso(Estado.ACCESOMAESTRO);
//LOGICA DE ENVIO y RECEPCION
if(estado.getPollingIntention())
estado.setAcceso(Estado.POLLING);
else
estado.setAcceso(0);
estado.leaveQueue();
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
61
- Proceso de finding
estado.isFindingDone(false);
if(estado.getAcceso() == Estado.ACCESOMAESTRO){
if(estado.getPollingIntention())
{
try{
estado.addUserToQueue(u,2);
}catch(Exception ex){
estado.addUserToQueue(u,1);
}estado.setAcceso(Estado.GETDIRECCIONES);
}else
estado.addUserToQueue(u,1);
}else
estado.addUserToQueue(u);
if(estado.getAcceso() == Estado.POLLING){
estado.setAcceso(Estado.GETDIRECCIONES);
}
}while(((User)estado.getQueue().get(0)).getPort() != -2){}
estado.setAcceso(Estado.GETDIRECCIONES);
estado.isFindingDone(false);
//LOGICA INTERNA
if(estado.getPollingIntention())
estado.setAcceso(Estado.POLLING);
else
estado.setAcceso(0);
estado.leaveQueue();
estado.isFindingDone(true);
Para más información, referirse a los comentarios del código.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
62
3.3.5 Programación de comunicación Modbus y control de obtención de respuestas.
El envío de tramas se hará directamente sobre un método de Estado.java
enviarTrama(String trama) utilizando las herramientas mostradas, sin embargo la
recepción se hará en un nuevo Thread ReceiveTrama.java
Diagrama 15: ReceiveTrama.java
Se ha establecido durante el diseño que para controlar la falta de respuesta de la red
se debía de incorporar un timeout a una instrucción. Evidentemente eso no es posible
en Java de forma directa, ni en ningún lenguaje de programación. Empezaremos a
manejar los parámetros necesarios en la ejecución de ReceiveTrama.java desde la
función recibeTrama() de Estado.java:
//EJECUCION DEL THREAD RECEIVETRAMA.JAVA DESDE ESTADO.JAVA\\
this.timeOver = false;
//Aqui controlaremos el timeout ó si hay respuesta antes\\
if(!this.getReadingModbus()){
ReceiveTrama rt = new ReceiveTrama(this);
Thread recibela = new Thread(rt);
//recibela SOLO escucha y crea tramas REALES.
recibela.start();
}
//bloqueamos:
while(timeOver
instruccion”
==
false
&&
tramaOutReady
==
false)
//”Timeout
de
{/*ESPERAMOS*/}
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
la
Memoria. RemModbus
63
Para poder continuar la ejecución se tendrá que modificar uno de los dos valores
timeOver o tramaOutReady, ReveiveTrama realizará las siguientes operaciones sobre
los atributos de control de respuesta de la instancia de Estado.java (a partir de este
momento, se conocerá simplemente como estado) para acabar modificando
tramaOutReady.
//INTERIOR DEL THREAD RECEIVE TRAMA\\
tramaReceived = new Trama();
estado.setTramaOutReady(false);
//modificacion de tramaOutReady
//trata de leer trama
//en caso de leer algo
estado.setTramaReceived(tramaReceived);
estado.setTramaOutReady(true);
//modificacion de tramaOutReady
Paralelamente a la ejecución de este hilo se ejecutará desde él, otro Thread
Timeout.java,
Diagrama 16: Timeout.java
//EJECUCION DE TIMEOVER.JAVA\\
estado.setTimeOver(false);
//modificacion de estado.timeOver
try{
sleep(time);
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
64
}catch (InterruptedException ie){
System.out.println("Fallo de Timeout");
}
if(!outdated){
estado.setTimeOver(true);
//modificacion de estado.timeOver
}
Donde time está establecido como 3000 ms, tiempo de sobra para que se realice una
transacción de ida y vuelta Modbus, y modificará el otro valor de estado timeOver,
que tiene bloqueada la ejecución. Una vez modificado uno de los dos atributos,
continuaria la ejecución.
//CONTINUA LA EJECUCION EN ESTADO.JAVA\\
to.isOutdated(true);
//modifica Timeover.java: timeover ya no es util
if(!tramaOutReady)
tramaReceived = new Trama("0x00");
Si se leyó algo de la red Modbus antes de que acabara Timeout, continuaría la
ejecución despreciándose el timeout. En caso contrario se crea una trama falsa.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
65
3.3.6 Programación del finding: FindDevices.java
Sigue el proceso típico:
-
Comienzo: Modificación de atributos implicados en estado
-
Desarrollo: Lógica + Modificación de atributos implicados en estado
-
Finalización: Modificación de atributos implicados en estado
Lógica
Dado que manejamos un campo de dirección o número de esclavo de 16 bits
(recordemos su representación lógica en hexadecimal: 0xAA) vamos a tener 216 − 1 =
255 direcciones posibles, de las que sabemos que 0xC7 y 0x00 no están disponibles.
Se creará un bucle desde i = 1 hasta i < 256 donde en cada iteración se enviará una
trama de prueba para ver si se obtiene respuesta. En caso afirmativo el valor
hexadecimal de el contador i se guardará en el ArrayList de dispositivos conectados.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
66
3.3.7 Programación del polling
Sigue el proceso típico:
-
Comienzo: Modificación de atributos implicados en estado
-
Desarrollo: Lógica + Modificación de atributos implicados en estado
-
Finalización: Modificación de atributos implicados en estado
Lógica
Trabajamos con dos ArrayList paralelos, uno con las tramas request y otro con las
response. Leemos en orden del ArrayList de request y guardamos el índice en el que
esta esa trama. Posteriormente la enviamos y recibimos la response que introducimos
el índice que obtuvimos anteriormente en el ArrayList correspondiente.
Puede darse el caso de que se haya cambiado el ArrayList sobre el q trabaja el
Iterator que estemos trabajando con información falsa. Esta situación se soluciona
actualizando un boolean en estado que indique que la trama ha cambiado, y, al final
de cada envió de trama en polling hacer la siguiente comprobación
if(estado.isTramasPollingChanged()){
tramasPolling = estado.getTramasPolling();
it = tramasPolling.iterator();
tramasPollingOut = new ArrayList();
}
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
67
3.3.8 Programación del CRC
El método de cálculo de CRC está localizado en la clase Trama, del paquete
pfc_dsm.Modbus. El propio método tiene un sistema para detectar si el CRC se ha
incluido previamente en la trama, no añadiéndolo por tanto. Esto es útil sobre todo
para la utilización como puente del sistema.
Se han tenido muchos problemas con la programación de esta suma de verificación.
Los diagramas no eran suficientemente claros y no se tenía conocimiento del
funcionamiento de los operadores de datos. Finalmente se optó por utilizar cadenas
binarias representadas sobre Strings. Para facilitar la comprensión del método se
muestran los dos campos del CRC que daría como resultado la trama 0x3F-0x63
0x3f
----------------------------------1111111111000000 tiene un 0 en vuelta0. desplazo todos los bits a la derecha
0111111111100000
0111111111100000 tiene un 0 en vuelta1. desplazo todos los bits a la derecha
0011111111110000
0011111111110000 tiene un 0 en vuelta2. desplazo todos los bits a la derecha
0001111111111000
0001111111111000 tiene un 0 en vuelta3. desplazo todos los bits a la derecha
0000111111111100
0000111111111100 tiene un 0 en vuelta4. desplazo todos los bits a la derecha
0000011111111110
0000011111111110 tiene un 0 en vuelta5. desplazo todos los bits a la derecha
0000001111111111
0000001111111111 tiene un 1 en vuelta6. desplazo todos los bits a la derecha
y XOR con 0xa001
1010000111111110
1010000111111110 tiene un 0 en vuelta7. desplazo todos los bits a la derecha
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
68
0101000011111111
----------------------------------0x63
----------------------------------0101000010011100 tiene un 0 en vuelta0. desplazo todos los bits a la derecha
0010100001001110
0010100001001110 tiene un 0 en vuelta1. desplazo todos los bits a la derecha
0001010000100111
0001010000100111 tiene un 1 en vuelta2. desplazo todos los bits a la derecha
y XOR con 0xa001
1010101000010010
1010101000010010 tiene un 0 en vuelta3. desplazo todos los bits a la derecha
0101010100001001
0101010100001001 tiene un 1 en vuelta4. desplazo todos los bits a la derecha
y XOR con 0xa001
1000101010000101
1000101010000101 tiene un 1 en vuelta5. desplazo todos los bits a la derecha
y XOR con 0xa001
1110010101000011
1110010101000011 tiene un 1 en vuelta6. desplazo todos los bits a la derecha
y XOR con 0xa001
1101001010100000
1101001010100000 tiene un 0 en vuelta7. desplazo todos los bits a la derecha
0110100101010000
0110100101010000
01010000 0110100
0x50 0x69
Nótese que del resultado final se divide en dos cadenas de 8 bits y se cambian de
posición.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
69
3.4 Programación de RemModbus Cliente
Figura 18: RemModbus Cliente
RemoteConnection.java es la única novedad que presenta el cliente frente a las clases
del servidor. Implementa todo lo necesario para la utilización del sistema: conexión,
funciones del servidor, recuperación de estado del servidor, comunicación modbus,
etc. Muchos de estos métodos que implementa como String modbusCommunication
(String trama) son los mismos que se utilizan en el servidor, ligeramente adaptados.
Para la implementación de puentes por ejemplo se utiliza una versión modificada de
ese mismo método modbusCommunication, que consiste en envolver ese método en
su
homonimo
del
servidor,
pero
invertido.
De
ahí
el
nombre
reverseModbusComunication():
Envía trama
Recibe trama
Figura 19: modbusComunication (server)
En el servidor este método simplente envía una trama a la red serie y recibe su
respuesta
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. RemModbus
70
Recibe
Envía
Recibe
Envía
trama
tramaInet
tramaInet
trama
Figura 20: reverseModbusCommunication (cliente)
La función para el cliente funciona inicialmente de la forma inversa. Escucha en un
puerto, y lo que recibe lo reenvía utilizando modbusComunication del cliente, la cual
invoca al método anteriormente mostrado [Figura 19], que tiene el mismo nombre. Se
ejecuta en el servidor y se obtiene la trama que es devuelta al cliente en “recibe
tramaInet” del gráfico. Finalmente esta trama se envía al puerto COM desde el que se
recibió la trama original.
4 API RemModbus
Se ha desarrollado una API siguiendo la estética de las APIs de Java. Para mas
información, se encuentra en la parte de Manuales de Usuario. Consulte el índice.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
71
Capítulo 3 WEBCP2003, REMCP2003 &
REMBRIDGE
1 Introducción
En este capítulo tiene como propósito centrarse en el diseño, fases y programación de
las aplicaciones que hacen uso remoto de la red Modbus mediante RemModbus.
No se prestara demasiada atención al diseño y programación de los programas
RemModbus2003 y RemBridge, ya que no presentan ningún tipo de complicación o
entramado a ese nivel, y se limitan a simplemente a instanciar la clase
RemoteConnection y utilizar los métodos no utilizados directa o claramente por
Web2003.
Por otro lado tenemos Web2003, que sí que es un sistema que consta de un completo
diseño y una buena programación. Está basado en el acceso a la red Modbus a través
de RemModbus como las otras, pero con la peculiaridad de que está montado sobre
un Web Service y ofrece sus servicios a través de un simple navegador Web, incluso
desde una PDA o un teléfono móvil.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
72
2 Requerimientos funcionales
[R01] Un usuario debe tener asignado un nivel. ‘Owner’ (nivel alto) ó ‘Subscriber’
(nivel bajo).
[R02] Solo podrán acceder al sistema los usuarios registrados en RemModbus.
[R03] Todo usuario del sistema sin nivel se le asignara el nivel ‘Subscriber’ para la
sesión.
[R04] El sistema debe mostrar los dispositivos conectados para todos los usuarios.
[R05] El sistema debe ofrecer una forma de establecer unas determinadas tomas de
medida para que el usuario añada o quite las que desee
[R06] Solo los usuarios de nivel alto pueden modificar que tomas de medida se
deben tomar en el servidor (polling)
[R07] Cualquier usuario independientemente de su nivel puede ver el estado de la
toma de medidas
[R08] Un ‘Owner’ debe poder administrar6 los usuarios de RemModbus.
[R09] Un ‘Owner’ debe poder ejecutar el proceso de descubrimiento de dispositivos
[R10] Cualquier usuario puede detener o arrancar el polling
[R11] El sistema no debe dejar arrancar un polling vacío.
[R12] El sistema debe mostrar cuándo esta ocupado el servidor, actualizando los
dispositivos conectados, y el tiempo estimado hasta que vuelva a quedar libre.
[R13] Todo usuario debe tener opción de consultar información a cerca de los
dispositivos conectados.
[R14] Todo usuario debe tener opción de desconectarse de RemModbus.
[R15] El sistema reconocerá situaciones en las que se pueda estar manejando
información obsoleta, y ofrecerá al usuario la opción de actualizarla
6
Administrar: Dar de alta nuevos usuarios, borrar usuarios, modificar usuarios
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
73
3 Requerimientos no funcionales
[NF01] La aplicación debe validar la información
[NF01] La aplicación debe utilizar Apache Tomcat como servidor.
[NF01] La aplicación debe ser desarrollada en JSEE.
[NF01] La aplicación debe utilizar tecnología basada en Servlets
[NF01] Las páginas mostradas deben ser JSP
4 Modelo de dominio
Diagrama 17: Modelo de dominio WebCP2003
El diagrama superior muestra los conceptos básicos del dominio del problema así
como las relaciones más importantes entre las entidades principales.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
74
5 Diagrama de casos de uso
Diagrama 18: Casos de uso WebCP2003
Se han plasmado las acciones que pueden realizarlos distintos tipos de usuario en
función de su nivel, a partir de la información plasmada en los requerimientos
funcionales. Se describe un caso de uso para la ayuda a su interpretación.
“Todo usuario de tipo Owner tiene opción de añadir una medida al polling, pero un
usuario de tipo Subscriber no”
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
75
6 Descripción de los casos de uso
Login
Actor principal
Usuario
Actor secundario
-
Condiciones
-
previas
Trigger
Submit del usuario
Escenario principal
Variaciones
1
El sistema muestra la página de acceso
2
El usuario rellena usuario y contraseña
3
El sistema reenvía a la página principal
2a. El usuario no rellena todos los huecos
2b. El usuario / contraseña son incorrectos
Excepciones
1
El sistema muestra página de error
2
El usuario confirma
3
Vuelta a 1
2a La conexión con RemModbus no está disponible
•
El sistema muestra página de error
•
El usuario confirma
•
Vuelta a 1
Logout
Actor principal
Usuario
Actor secundario
-
Condiciones
-
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
76
previas
Trigger
Selección del usuario
Escenario principal
Excepciones
1
El usuario pulsa Logout
2
El sistema reenvía a la página de login
2a La conexión con RemModbus no está disponible
•
El sistema muestra página de error
•
El usuario confirma
•
Vuelta a 1
Ver dispositivos Modbus
Actor principal
Usuario
Actor secundario
-
Condiciones
-
previas
Trigger
Escenario principal
Operación de Servlet
1
El sistema muestra la página de bienvenida con los
usuarios conectados
Variaciones
1a. No hay dispositivos conectados
1b. El servidor se está actualizando
1
El
sistema
muestra
el
(los)
correspondiente(s) en la misma página y
aviso(s)
ofrece
actualizar el estado
2
El usuario confirma
3
Vuelta a 1
1a.2a. El usuario no confirma
1b.2a. El usuario no confirma
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
1
Excepciones
77
No se actualiza hasta la siguiente acción de servlet.
2a La conexión con RemModbus no está disponible
•
El sistema muestra página de error
•
El usuario confirma
•
Vuelta a pagina de inicio
Ver medidas de un dispositivos Modbus
Actor principal
Usuario
Actor secundario
-
Condiciones
-
previas
Trigger
Selección de usuario
Escenario principal
1
El usuario elige un dispositivo de la lista de
dispositivos
2
El sistema muestra la página del dispositivo con las
medidas
Variaciones
-
Excepciones
1a La conexión con RemModbus no está disponible
•
El sistema muestra página de error
•
El usuario confirma
•
Vuelta a pagina de inicio
2a. La información puede estar obsoleta
2b. El servidor se está actualizando
•
El
sistema
muestra
el
(los)
correspondiente(s) en la misma página y
aviso(s)
ofrece
actualizar el estadoEl usuario confirma
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
78
Editar medidas de un dispositivos Modbus
Actor principal
Usuario
Actor secundario
-
Condiciones
Estar en la página de dispositivo
previas
Trigger
Usuario Owner
Selección de usuario
Escenario principal
1
El usuario elige una medida de la lista de medidas
para observar o dejar de observar
2
El sistema muestra que se ha modificado el polling.
Cada vez que se muestre una página se debe de
ofrecer la opción de actualizarlo en el servidor o de
deshacer los cambios
Variaciones
-
Excepciones
1a La conexión con RemModbus no está disponible
•
El sistema muestra página de error
•
El usuario confirma
•
Vuelta a pagina de inicio
2a. La información puede estar obsoleta
2b. El servidor se está actualizando
•
El
sistema
muestra
el
(los)
correspondiente(s) en la misma página y
aviso(s)
ofrece
actualizar el estadoEl usuario confirma
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
79
Actualizar polling en el servidor
Actor principal
Usuario
Actor secundario
-
Condiciones
Usuario Owner
previas
Trigger
Selección de usuario
Escenario principal
1
El usuario elige una medida de la lista de medidas
para observar o dejar de observar
2
El sistema lo actualiza y retira el mensaje de polling
modificado.
Variaciones
-
Excepciones
1a La conexión con RemModbus no está disponible
•
El sistema muestra página de error
•
El usuario confirma
•
Vuelta a pagina de inicio
1b. La información puede estar obsoleta
1c. El servidor se está actualizando
•
El
sistema
muestra
el
(los)
correspondiente(s) en la misma página y
aviso(s)
ofrece
actualizar el estadoEl usuario confirma
Administrar usuarios
Actor principal
Usuario
Actor secundario
-
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
Condiciones
80
Usuario Owner
previas
Trigger
Selección de usuario
Escenario principal
1
El sistema muestra que el usuario tiene permisos
para administrar usuarios
2
El usuario selecciona la opción
3
El sistema muestra los usuarios, contraseñas y
permisos.
4
El usuario realiza alguna actualización
5
El sistema ejecuta la decisión del usuario y refresca
la página.
Variaciones
-
Excepciones
1a La conexión con RemModbus no está disponible
•
El sistema muestra página de error
•
El usuario confirma
•
Vuelta a pagina de inicio
2a. La información puede estar obsoleta
2b. El servidor se está actualizando
•
El
sistema
muestra
el
(los)
correspondiente(s) en la misma página y
aviso(s)
ofrece
actualizar el estadoEl usuario confirma
5a. Fallo de la base de datos
•
El sistema muestra página de error
•
El usuario confirma
•
Vuelta a pagina de inicio
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
81
Start/Stop de Polling
Actor principal
Usuario
Actor secundario
-
Condiciones
-
previas
Trigger
Selección de usuario
Escenario principal
1
El sistema muestra la opción de arrancar o parar el
polling en función de como esté, siempre que no esté
vacío.
2
El usuario selecciona Start/Stop
3
El sistema ejecuta la operación y refresca la página
Variaciones
-
Excepciones
1a La conexión con RemModbus no está disponible
•
El sistema muestra página de error
•
El usuario confirma
•
Vuelta a pagina de inicio
2a. La información puede estar obsoleta y el polling haber
sido arrancado o detenido por otro proceso.
•
El sistema comprueba el estado del servidor y lo
compara con el de la aplicación antes de continuar
con el cambio de estado
2b. El servidor se está actualizando
•
El
sistema
muestra
el
(los)
correspondiente(s) en la misma página y
aviso(s)
ofrece
actualizar el estadoEl usuario confirma
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
82
Start de Finding
Actor principal
Usuario
Actor secundario
-
Condiciones
Usuario Owner
previas
Trigger
Selección de usuario
Escenario principal
1
El sistema muestra la opción de arrancar el finding
si tiene sospecha de que está obsoleto.
2
El usuario selecciona Start
3
El sistema ejecuta la operación y refresca la página
Variaciones
-
Excepciones
1a La conexión con RemModbus no está disponible
•
El sistema muestra página de error
•
El usuario confirma
•
Vuelta a pagina de inicio
2a. La información puede estar obsoleta y el finding puede
haber sido arrancado o detenido por otro proceso.
•
El sistema comprueba el estado del servidor y lo
compara con el de la aplicación antes de continuar
con el cambio de estado
Hay bastantes más casos de uso pero dado que todos siguen la misma lógica no se
añadirán más a este documento.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
83
7 Diagramas de secuencia
A continuación se mostraran los diagramas de secuencia de los procesos más
importantes y una breve explicación de los mismos si procede.
7.1 Procesos de login y logout
Diagrama 19: Secuencia de Login
El proceso se fundamenta en la creación de un nuevo usuario, su validación en el
servidor por medio de RemoteConnection, y su actualización con el permiso. La
creación y uso de Display se explicará más adelante. Se envía el control a
WelcomeServlet cuyo diagrama de secuencia se encuentra también detallado.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
84
Diagrama 20: Secuencia de Logout
Si un usuario desea desconectarse, deberá poder hacerlo en cualquier página por eso
sería interesante incluir un botón de logout en todas las cabeceras de página. El
proceso de desconexión o logout es muy simple, ya que no requiere nada más que
solicitar la acción a RemoteConnection. A continuación se destruyen user y
RemoteConnection para permitir nuevas conexiones y no tener datos de sesión.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
85
7.2 WelcomeServlet
En adelante todo forward que se haga sobre WelcomeServlet hará las siguientes
operaciones indicadas en el diagrama que sigue
Diagrama 21: Secuencia de WelcomeServlet
La sesión se actualizará en términos de dispositivos conectados y lista de tramas de
polling. El sistema Web ofrece un sistema que permite reconocer situaciones
potenciales de información obsoleta. Unos ejemplos de situación potencial de
información obsoleta, serían
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
86
que las tramas de polling de medidas no puedan ser interpretadas
que una consulta de petición de número de serie devuelva error
que las tramas de polling se hayan modificado en la aplicación Web y no estén
actualizadas
etc.
El sistema se ha diseñado para que la página JSP ‘welcome’ sea una especie de
escritorio para el usuario, por lo que la mayor parte del tiempo la invertirá en ella. Es
por eso que cualquier aviso ante situaciones como la anterior, o cualquier otro
relacionado con las acciones que pueda realizar a cabo el usuario dependiendo de la
situación, se realicen en dicha página. A la hora de programar esto lo hemos
solucionado con variables verdadero/falso que se estructuran dentro de la clase
Display, para mantener más orden en HttpSession. Así por ejemplo mostraremos los
mensajes oportunos cuando sea necesario:
<!—Codigo adaptado de welcome.jsp-->
<% if (display.isFindingRunning()) {%>
<h3><br>
<form method="POST" action="welcome" name="eta">
<table width="90%" border="0">
<tr>
<td width="669"><div align="left">
<p> <!-–(…)--> servidor se esta actualizando <!-–(…)--> </p>
</td>
<td width="89"><input type="submit" value="Actualizar"></td>
</tr>
</table><br>
</form>
</h3><br>
<% } %>
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
87
7.3 Ver medidas de un dispositivo
Diagrama 22: Secuencia de Ver un Dispositivo
Muestra el proceso que se sigue para mostrar las medidas que se están tomando o se
pueden tomar del dispositivo seleccionado en la pantalla anterior. En resumen, la JSP
encargada de mostrar esa información accederá a los datos necesarios, que
ViewDeviceServlet ha preparado para ella. Nótese que puede ser también entendido
el diagrama como el diagrama de secuencia de ViewDeviceServlet, desde la
instrucción 1.1.1.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
88
Interpretando los datos
[Para más información, consultar Anexo 1: CP200X Communication Protocol]
El dispositivo CP2003, aunque es extensible a muchos dispositivos Modbus, ofrece
la información en cinco formatos diferentes.
-
ASCII: Como caracteres, enviados en el orden específico. Utilizado
para operaciones como lectura del número de serie, etc.
-
BYTE: Ocho bits. Utilizado para parámetros de estado o control
-
WORD: 16 bits, dos Bytes. Enviado como: MSB7-LSB8
-
LONG: Cuatro Bytes. Enviados como: MSB-[ ]-[ ]-LSB
-
IEEE: Cuatro Bytes. Es el utilizado para las medidas de polling de
WebCP2003, en el CP200X.
El formato IEEE (coma flotante)
La interpretación y programación de esto ha sido complicada. Se explicará como se
ha de interpretar la información de este tipo. Como hemos visto se deben leer cuatro
Bytes, que tendrán la siguiente información:
BYTE1: SIGNO + EXPONENTE
BYTE2: MANTISA HIGH
BYTE3: MANTISA MIDDLE
BYTE4: MANTISA LOW
7
Most Significative Bit: Bit más significativo
8
Less Significative Bit: Bit menos significativo
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
89
Hay que tener en cuenta que la posición real de esos Bytes no se ajusta a esa
numeración sino que hay que modificar la posición de las parejas de WORDS. Asi
por ejemplo el hipotético PDU recibido de una trama 0x0A-0x00-0x43-0x5E, sería
de acuerdo a la numeración establecida arriba: 0x43(Byte1), 0x5E(Byte2),
0x0A(Byte3), 0x00(Byte4)
Si SIGNO es el valor binario 0 quiere decir positivo, si es 1 quiere decir negativo.
EXPONENTE (EXP) es el exponente, con offset 127.
Para hallar el valor:
Ecuación 2: Cálculo de dato IEEE
(
)
(
)
23


Value = − 1SIGNO * 2 EXP −127 * 1 + ∑ 2 −i * M i 
i =1


Para hallar el valor de los parámetros:
Byte1
7
Byte2
6
SG E7
5
4
3
E6 E5 E4
2
1
0
E3 E2 E1
7
6
5
3
2
1
0
E0 M1 M2 M3 M4 M5 M6 M7
EXPONENTE
MANTISA ->
Byte3
7
4
Byte4
6
5
4
3
2
1
0
M8 M9 M10M11M12M13M14 M15
7
6
5
4
3
2
1
0
M16M17M18M19M20 M21M22M23
<- MANTISA
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
90
7.4 Editar medidas
Diagrama 23: Secuencia de Editar Medidas del Polling
Se debe tener en cuenta que después de la acción detallada el sistema Web no estará
en concordancia con el sistema RemModbus. WebCP2003 mostrará un aviso con dos
opciones, deshacer los cambios (recargaría el polling del servidor) o actualizar el
polling en el servidor (modificar el polling del servidor). Para estas opciones, como
para las demás que se presentan se utilizarán los métodos de RemoteConnection.
Consultar la API desarrollada y adjunta para más información.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
91
7.5 Administrar usuarios
El diagrama se divide en dos partes, la de acceso a la página de edición de usuarios y
la de la administración en si.
Diagrama 24: Secuencia de Administrar Usuarios
Solo si un usuario es Owner se le mostrará la opción de administrar a los usuarios.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
92
7.6 Arrancar procesos en el servidor
Diagrama 25: Secuencia de Arrancar Finding
En el diagrama se muestra como ejemplo como funciona la lógica que hace al
proceso de finding ser arrancado por el usuario. Se ha escogido este ejemplo porque
en esencia hace lo mismo que el proceso de arrancar polling, pero tiene menos
operaciones de actualización y la secuencia se ve más clara. Si se presta atención al
punto 3, se solicita el estado del finding antes de arrancarlo. Esto se hace por si el
proceso ha sido arrancado mientras la página no era refrescada. Hay que tener en
cuenta también que normalmente esto no sucederá ya que ese mismo proceso de
reconocimiento se hace a menudo, para tener el sistema actualizado el mayor tiempo
posible.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. WebCP2003, RemCP2003 & RemBridge
8 RemCP2003
Ilustración 1: RemCP2003
Esta aplicación modular tendrá como objetivos
probar la conexión a RemModbus desde una aplicación Java
probar el uso de una comunicación Modbus (request – response)
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
93
Memoria. WebCP2003, RemCP2003 & RemBridge
94
9 RemBridge
Esta aplicación modular será una utilidad que permitirá establecer de forma
transparente, un puente RS232 virtual entre un puerto COM del cliente y el puerto
que conecta a RemModbus a la red de dispositivos.
Por favor, refiérase al Capítulo 2 RemModbus, apartado 3, Programación y pruebas,
para la correcta y siga los pasos de instalación de librerías de RemModbus. Además
se precisará crear dos puertos COM virtuales y establecer una comunicación entre
ellos. Existen programas ya desarrollados con esa finalidad como VSPD XP4.
Modbus app sobre RemBridge
RemModbus Servidor
INET
virtual
COM2
COM3
COM1
ESCLAVO
TCP/IP
TCP/IP
Figura 21: Lógica RemBridge
COM1 y COM2 son puertos virtuales con una conexión virtual entre ellos de manera
que lo que envía uno, es recibido por el otro. RemBridge escucha en COM2 y una
aplicación Modbus local cualquiera se conecta a COM1 como si el dispositivo
estuviera conectado a ese puerto y envía una trama. Al recibir información
RemBridge la reenvía por TCP usando RemModbus.RemoteConnection. La trama se
procesa como un DAT_ABS (ver diseño de protocolo RemModbus) y se envía la
respuesta. RemBridge la recibe y la transmite a COM2, por lo que la aplicación
Modbus recibirá esa información de COM1.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Resultados/Experimentos
95
Capítulo 4 RESULTADOS/EXPERIMENTOS
1 RemModbus
Es una aplicación que de forma remota y local,
Permite administrar una red Modbus.
Proporciona la comunicación básica Modbus: intercambio de tramas.
Permite mediante una instanciación muy sencilla, el acceso de cualquier
aplicación Modbus a la red, de forma remota.
Permite acceso múltiple a la aplicación.
Permite varios dispositivos Modbus conectados
Ofrece facilidades de uso de Modbus a programadores industriales
generalmente
Ofrece una documentación en forma de API que facilita aún más la
programación y el diseño de aplicaciones Modbus.
Permite control de acceso a la red e implantación de niveles de usuario.
Permite ejecutar una serie de instrucciones sobre la red y obtener los
resultados, algo que hemos llamado `polling`.
Ofrece una utilidad de búsqueda automática de dispositivos Modbus
conectados a la red, a la que hemos dado el nombre de ‘finding’
Ofrece control y recuperación de errores sobre una arquitectura que
originalmente no la tiene (Modbus)
Permite un enlace transparente con la red Modbus y con el protocolo
RemModbus.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Resultados/Experimentos
96
2 WebCP2003
Es un servidor Web que esta diseñado para obtener de forma remota información de
uno o varios dispositivos CP2003 y además,
Administra el polling de medidas a tomar sobre la red
Administra el estado de la red Modbus. Se sabe en todo momento que
dispositivos tiene conectados, si está funcionando el polling, si un
dispositivo no está funcionando correctamente, etc.
Administra los usuarios de la red a la que nos conectamos.
Considera el nivel de usuario para establecer responsabilidades.
Está montado sobre RemModbus.
3 RemCP2003
Programa Java para la ejecución de consultas definidas sobre un CP2003.
Implementar la comunicación básica “request-response”.
4 RemBridge
Una instanciación de la utilidad de RemModbus para la creación de puertos virtuales
Permite acceder a la red administrada por RemModbus y por tanto a sus
dispositivos de forma totalmente transparente. Cualquier aplicación
interactuará con la red de forma remota sin saberlo.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Resultados/Experimentos
97
5 Experimentos
Durante el estudio del diseño de la arquitectura física de la red Modbus, se reparó en
el convertidor hardware de señal RS232 a RS485. Surgió la idea de realizar la
conversión entre los protocolos por medio de software, por lo que se procedió al
estudio preliminar de la señal. Se conectó un osciloscopio al sistema y se estudiaron
las tramas capturadas a cada uno de los lados del convertidor. Se observaron que las
diferencias entre ambas eran mínimas, ya que lo que variaba de una a otra era el
significado de 1 y 0 (tensión en uno, y no tensión en el otro). Aparentemente la
intensidad también variaba. Sin embargo implementar este método hubiera supuesto
demasiado estudio de la situación y arquitectura de los medios de transmisión, ya que
no se sabía si físicamente se podía hacer.
También se ha descartado la idea de la actualización automática de dispositivos
conectados, ante un error. Esto es que cuando una trama que se ejecuta sobre un
dispositivo no responde, el sistema supone que el registro de dispositivos conectados
no está actualizado, y arranca el proceso de finding. Esta función estuvo implantada
durante mucho tiempo en el sistema, pero finalmente se retiró de él por dos razones
importantes: La primera, que dada la lógica de colas implantada, se ralentizaba el
sistema en situaciones en las que no era absolutamente necesario, y la segunda, que
se pensó que no era una competencia directa del sistema local.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Conclusiones
98
Capítulo 5 CONCLUSIONES
Hay que tener en cuenta que se carecía de base alguna acerca de cómo funcionaban
los entornos o las comunicaciones industriales antes del desarrollo de la aplicación.
Normalmente no son ámbitos de los que un ingeniero informático tenga un buen
nivel de conocimiento, por su bajo nivel, muy especializado o al detalle de bit. Es por
tanto que se ha requerido mucho tiempo de familiarización con los dispositivos y de
estudio de arquitecturas y de alternativas de desarrollo. Se ha gastado mucho tiempo
consultando distintas páginas de Internet, con informaciones incompletas o
contradictorias, hasta que finalmente se ha tenido un concepto claro. Es por esto que
el desarrollo de este proyecto me ha permitido familiarizarme no solo con el
protocolo Modbus o con el dispositivo CP2003, sino con todo su entorno. Por
ejemplo antes del proyecto nunca antes había utilizado un osciloscopio, un plc o un
pupitre de mando, de los que lo más que tenía en el mejor de los casos, era una ligera
idea.
He comprobado en mi propio pellejo que la mejor manera de afrontar un problema,
es dividirlo en problemas más sencillos, e ir atajándolos poco a poco. Me he
divertido haciendo el proyecto y también lo he pasado mal. Me he visto superado por
la funcionalidad que debía tener el proyecto, y he sabido cómo solucionarlo.
Se ha mejorado la capacidad de diseño. Además se ha comprobado que el tiempo que
se pierde diseñando o elaborando diagramas, se gana a la hora de programar. Un muy
buen diseño puede convertirse en una especie de guión para el programador, donde
este solo tenga la necesidad de diseñar. El buen diseño en este proyecto ha permitido
la creación de utilidades que facilitan la programación. El ejemplo más claro es
RemModbus pero esa filosofía la encontramos también a lo largo de todo el
proyecto, por ejemplo en la definición de un protocolo de comunicación por Internet.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Conclusiones
99
Se han utilizado una gran cantidad de tecnologías lo que ha mejorado mi
programación y más concretamente mi manejo de Java, HTML, SQL, CSS, Servlets,
etc. Se han aprendido muchas técnicas de programación: el uso de ciertas clases de
Java, operadores de datos, etc.
Finalmente se han conseguido cumplir los objetivos planteados inicialmente, y todos
los secundarios que han ido surgiendo durante el proceso de diseño y de
programación. Personalmente espero que nuestro proyecto pueda se realmente útil,
ya sea en su programación, su diseño, o en su concepto, y pueda ser utilizado por
otros programadores o usuarios.
Es importante destacar la aportación realizada, de desarrollar una herramienta y su
API para desarrollar el objetivo inicial, que consistía simplemente en desarrollar una
aplicación que se conectara remotamente un dispositivo Modbus, el CP2003. Esto
nos hizo cambiar el alcance de la aplicación, limitando un poco la funcionalidad que
tendría inicialmente la aplicación inicial, y desarrollando dos sistemas más
modulares que realicen las operaciones sobre el dispositivo, pero añadiendo el valor
añadido de RemBridge (Ver Capítulo 3, apartado RemBridge). Con esta aportación
ampliamos el rango de utilización a otras aplicaciones Modbus que funcionen sobre
otros dispositivos, y facilitamos el desarrollo de otras aplicaciones aumentando
considerablemente el grado de abstracción sobre detalles técnicos.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Futuros desarrollos
100
Capítulo 6 FUTUROS DESARROLLOS
Para poder aseverar que el proyecto se ha terminado y puede ser distribuido quedan
cosas por hacer. Cosas que aún no podemos saber. A pesar de que ambas partes del
proyecto ya pueden ser utilizadas y ser útiles, es muy posible que muchos
desarrolladores a la hora de utilizar RemModbus, por ejemplo, sientan que necesitan
más opciones en el servidor. Sé que esto puede suceder, puesto que me ha sucedido a
mi mismo, a pesar del buen diseño del sistema, del que se hace gala con anterioridad.
Es importante que otros diseñadores y programadores creen aplicaciones reales para
ver que necesidades, no pueden ser satisfechas por el sistema. Afortunadamente El
diseño de la aplicación es tan flexible y modular que permite añadir fácilmente
nuevas funcionalidades.
Por otra parte los programas de utilización de CP2003 están orientados a satisfacer
unos objetivos muy puntuales y no implementan toda la funcionalidad del
dispositivo, que es mucha. Futuros desarrollos pueden tener en cuenta esta situación,
y acabar construyendo un controlador remoto del CP2003, en el que se implementen
todas las opciones que ofrece CP2003.
En el caso de RemBridge estamos dependiendo de alguna aplicación que cree un
puente y dos puertos COM virtuales, y los conecte entre ellos. Con más tiempo se
podría haber incluido esta faceta en el alcance o el ámbito del proyecto. Sería muy
interesante desarrollar este punto, aunque el desarrollo de la API para programadores
perdería un poco de sentido, o mejor dicho, de utilidad.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Futuros desarrollos
101
Además, hay elementos que se ha visto que pueden hacer la aplicación más flexible o
más funcional como por ejemplo:
Cambio de base de datos. Actualmente se utiliza y no se ofrece la posibilidad
de cambiar, una base de datos en un servidor de Internet, al que se accede
mediante un puerto determinado. En algunas redes públicas o compartidas no
se podrán realizar conexiones a ese puerto. Adicionalmente hace que la
aplicación sea dependiente de un elemento absolutamente externo y estático.
Se recomienda implementar un método que permita de forma automatizada:
1. Cambiar la localización de la base de datos.
2. Crear las tablas necesarias.
3. Incluir un registro por defecto, que permita el acceso, del tipo
USER=admin, PASS=root, PERMISSION=full
Convertir señal RS232 a RS485 por software. Estudiar la posibilidad real de
realizar esta conversión. Ver capítulo de Resultados/Experimentos para más
información.
Permitir comunicación Modbus ASCII [Ver Programación RemModbus].
Llevaría un tiempo cambiar la lógica pero no sería complejo el diseño. Se
ofrecen ideas de referencia para su implantación.
1. Establecer protocolo que usa la red en el servidor RemModbus.
2. Establecer tramas SYN para modificar el protocolo y permitir que el
cliente sepa cómo está funcionando el sistema.
3. Creación alternativa de Trama.java
Establecer utilidades que creen el formato típico de las tramas cuando se
comunican entre procesos o aplicaciones, a partir de ArrayList(), Vector(),
etc. Y la utilidad inversa. Se podría haber implementado ya pero no se tenía
la necesidad ya que cuando surgió la idea ya no era necesario.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Futuros desarrollos
102
Estudiar la posibilidad o la utilidad de implementar en el servidor de
RemModbus o en una aplicación que se conecte, el envío de e-mails ante
medidas tomadas que se hayan preestablecido como peligrosas o dignas de
observación. Estudiar si es competencia de RemModbus o de aplicaciones
que hagan uso de el.
Actualmente se guarda solamente la última respuesta a una trama de polling.
Se propone guardar un historial de las últimas respuestas a una misma trama
de polling. Esto puede permitir a aplicaciones tipo WebCP2003 realizar
gráficas de evolución y permitir un estudio más exhaustivo de la evolución de
los resultados del polling. Estudiar si es competencia de RemModbus o de
aplicaciones que hagan uso de el.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Estudio Económico
103
Capítulo 7 ESTUDIO ECONÓMICO
1 Planificación previa
Ilustración 2: Planificación inicial
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Estudio Económico
104
2 Uso real aproximado del tiempo invertido en el proyecto
Investigación y aprendizaje: 60 horas
Identificación de necesidades: 15 horas
Diseño: 120 horas
Programación: 100 horas
Pruebas: 20 horas
Teniendo en cuenta que algunas actividades se solapan, el trabajo habrá llevado unas
300 horas. Si a esto le añadimos la documentación, nos moveríamos en torno a las
350 horas.
3 Valoración económica
Se quiere estimar el coste real del proyecto, incluyendo horas de trabajo, software y
hardware y material empleado para el aprendizaje.
Equipo (a 3 años): 200 €
Software (VSPD XP4): 90 €
Horas de trabajo: 7000 €
Libros: 100 €
COSTE TOTAL DEL PROYECTO: 7400 €
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Bibliografía
105
BIBLIOGRAFÍA
[1]
Eckel, Bruce Thinking in Java (3rd Edition Revision 4)
(2002) Prentice Hall.
[2]
Barranco de Areva, J. Metodología del análisis estructurado de sistemas.
(1994) Universidad Pontificia Comillas, Libros de texto (20), Madrid.
[3]
Bowman, J.S.; Emerson S.L.; Darnovsky, M.; The practical SQL Handbook (3rd
Edition)
(1997) Addison-Wesley Developers Press.
[4]
Castro Ponce, M. Tecnología de Computadores.
(1999) Universidad Pontificia Comillas, Encuadernaciones. Madrid.
[5]
Tejedor, Miguel Redes de Computadores (Vol. 1.)
(2004) Universidad Pontificia Comillas, Encuadernaciones. Madrid.
[6]
Tejedor, M.; Castro Ponce, M. Redes de Computadores (Vol. 2).
(2004) Universidad Pontificia Comillas, Encuadernaciones. Madrid.
[7]
Rodríguez Mondéjar, J.A.; Fundamentos de Comunicaciones Industriales.
Universidad Pontificia Comillas, Practicas de Laboratorio.
[8]
Rodríguez Mondéjar, J.A.; Comunicaciones Industriales Avanzadas.
Universidad Pontificia Comillas, Practicas de Laboratorio.
[9]
Jiménez Buendía, M.; Comunicaciones Industriales
Universidad Politécnica de Cartagena, Departamento de Tecnología
Electrónica.
[10]
Ruiz Olaya, L.F.; Implementación de una red Modbus/TCP
(2002) Escuela de Ingeniería Eléctrica y Electrónica de Santiago de Cali, Tesis
[11]
SACI, CP2003 Communication Protocol
(2001) SACI, Manuales
[12]
Guías, Manuales y Especificaciones: http://www.modbus.org/specs.php
[13]
http://www.simplymodbus.ca/FAQ.htm
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Memoria. Bibliografía
[14]
http://jamod.sourceforge.net/kbase/protocol.html
[15]
http://www.rtaautomation.com/modbustcp/index.html
[16]
http://www.intellicom.se/ModbusTCP_overview.shtml
[17]
http://java.sun.com/products/javacomm/reference/api/index.html
[18]
http://java.sun.com/j2se/1.4.2/docs/api/
[19]
http://es.wikipedia.org/wiki/ y http://en.wikipedia.org/wiki/
[20]
http://java.sun.com/products/javacomm/reference/faqs/index.html
106
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Bibliografía
107
ANEXO I MANUALES DE
USUARIO
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. API de RemModbus
108
Capítulo 1 API DE REMMODBUS
Package pfc_dsm.RemModbus
Class Summary
RemoteConnection
A remote connection with a RemModbus application
pfc_dsm.RemModbus
Class SerialPort
java.lang.Object
pfc_dsm.RemModbus
public class RemoteConnection
Provides full access, for use and administration, for implementations of the
RemModbus server application. Please refer to the official documentation for further
generic or specific information.
Author:
Daniel Segura Martínez
Field Summary
static int
MAIN_PORT
Port number where the server receive incoming connections
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. API de RemModbus
109
Constructor Summary
RemoteConnection(String ip, String user, String pass)
Creates a new connection with the RemModbus server application.
Parameters:
ip – the ip direction where the RemModbus server app is located.
user – nickname or login name.
pass – password of the user.
Method Summary
String
getModbusIds()
Obtains the last revision of the connected devices of the client
Return Format:
“01-02-03”…
String
getPermission()
Returns the permission status of the user
String
getPollingResults()
Obtains the results of the polling from the server
boolean
getPollingStatus()
Obtains whether the polling is running or not, from the server
boolean
getServerStatus()
Obtains whether the finding is running or not, from the server, and
updates the ETA time from the server
String
getUser()
Returns the nickname of the user
boolean
isConected()
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. API de RemModbus
110
Obtains whether the system is connected or not, from the server
boolean
logout()
Ends the connection with the server
String
modbusCommunication(String modbusIn, int tipo)
Obtains the Modbus net response for the modbusIn frame with the
format “0x01-0x02-0xa0”
Parameters:
modbusIn – frame to be transmitted in the server system.
tipo – Specifies whether the frame will be transmitted even
if the server is busy or not. Positive case means that the
client will have to wait until the server finish.
Values:
1 for transmit even if the server is busy
2 for transmit if the server is not busy
Return Format:
“0x01-0x02-0xa0”
Return Values:
starting with “0x00” if no response is obtained or server is
busy (case tipo = 2)
normal return format in at any other situation
void
reverseModbusCommunication(String com, int baud, int
databits, int stop, int parity, int flows)
Establishes a virtual bridge between the local COM port and the
remote COM port.
Parameters:
com – Local COM port where we want to listen
baud – Specifies the baud rate
databits – Specifies the data bits
stop – Specifies the stop bits
parity – Specifies the parity
flows – Specifies the flow control
Formats:
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. API de RemModbus
111
“0x01-0x02-0xa0”
boolean
runFinding()
Starts the finding process in the server, and returns false if the
process could not be started. Updates ETA time from the server.
void
runModbusListening(boolean modbusConnected)
boolean
runPolling()
Starts or stop the polling process in the server. Returns the polling
status in the server
String
setLink()
Returns the permission status of the user
String
updateDevicesFromServer()
Returns the last connected devices list from the server or “Error”
boolean
updateDevicesInServer()
Deprecated. Forces the finding process to be executed in the server
String
updatePollingFromServer()
Returns the polling list from the server or “Error”
boolean
updatePollingInServer(String pollList)
Sets the new polling frames into the server logic. And returns the
status of the operation.
Parameters:
pollList – the frame list to be executed in the server. It
needs to have the followinf format:
“0x01-0x02-0xa0&0x02-0x02-0xa0&0x01-0x32-0xa0”…
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de RemModbus
112
Capítulo 2 MANUAL DE REMMODBUS
Este capítulo contendrá una breve descripción del servidor RemModbus y su manejo.
Ilustración 3: RemModbus Servidor
Para empezar a administrar la red Serie y las conexiones entrantes debemos pulsar
sobre los botones de conexión a red Modbus y red TCP/IP. Es importante que ambos
botones se activen para un correcto funcionamiento del servidor. Al pulsar sobre el
primero de ellos, se abrirá la ventana que se muestra a continuación. Sobre ella
tendremos que elegir bajo qué parámetros vamos a controlar la red Modbus.
(Velocidad de transmisión, bits de parada, puerto COM que proporciona la conexión
a la red, etc.)
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de RemModbus
113
Ilustración 4: Configuración de la conexión Modbus
Mediante el menú desplegable “Menú” de la parte superior de la aplicación
tendremos acceso a los procesos de finding y polling. El menú “Administración”
debe ser manejado con cuidado ya que permite modificar parámetros internos del
programa.
Ilustración 5: Menú Administración
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de RemModbus
114
La primera opción nos permitirá introducir manualmente los dispositivos que están
conectados a la red. Esto puede ser muy útil si no se quiere esperar al proceso de
descubrimiento de dispositivos, pero es necesario conocer el número de esclavo de
los dispositivos de antemano.
Ilustración 6: Introducir direcciones manualmente
Para modificar el resto de las opciones del menú se abrirán ventanas similares a la
anterior. La segunda opción nos va a permitir limitar el rango de direcciones en las
que buscar con el finding. Por ejemplo, si el administrador de la red sabe que todos
sus dispositivos se encuentran entre el 0x00 y el 0x0F, no tiene por que esperar a que
busque también desde el 0x10 al 0xFF. La última de las opciones de este menú sirve
para decidir cuánto deseamos esperar antes de suponer que la red no contestará a la
trama.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de RemModbus
115
Ilustración 7: RemModbus funcionando
RemModbus se estructura en 5 ventanas principales, cada una con una finalidad
informativa. La primera muestra la actividad local e interacción con la red Modbus,
mientras que la de debajo suyo (Acceso Remoto) se ocupa de las acciones llevadas a
cabo por los usuarios conectados mediante los programas que funcionan con
RemModbus. En las ventanas de la derecha vemos los detalles de los procesos de
polling y finding, y los usuarios conectados con su puerto asignado.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de WebCP2003
116
Capítulo 3 MANUAL DE WEBCP2003
1 Entrar en la aplicación
Ilustración 8: Entrando en WebCP2003
Esta es la primera página de la aplicación. Para evitar complicaciones se ha
establecido un usuario ya registrado y su contraseña en la pantalla de inicio. Una vez
validados pasaremos a la página principal de la aplicación, la cual está concebida
como una especie de escritorio desde el cual podremos acceder a las distintas
opciones de manejo de la red Modbus, controlada por RemModbus, así como a los
detalles de cada dispositivo CP200X
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de WebCP2003
117
2 Sistema inteligente de interacción
El manejo de la aplicación Web esta fundamentado en un sistema inteligente
desarrollado exclusivamente para evaluar el estado en el que se encuentra la red, y
ofrecer las diferentes opciones disponibles o más lógicas para cada situación
concreta. Esto se ha llevado a cabo mostrando mensajes emergentes en la pantalla
principal antes mencionada, que informan de la situación actual y las posibilidades
de interacción en ese marco. El manejo es muy intuitivo y fácil de comprender. A
continuación se muestra un ejemplo del funcionamiento con dichos mensajes.
Ilustración 9: Sistema inteligente de interacción
Vemos en la ilustración como el sistema ha detectado una situación potencial de
información obsoleta, y vemos también como ofrece dos soluciones posibles. Por
otra parte, se muestra que el servidor aun no tiene actualizada la lista del polling que
se ha confeccionado, y presenta la forma de hacerlo. En el último aviso vemos como
se detecta que el usuario tiene un nivel adecuado para administrar los usuarios.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de WebCP2003
118
3 Interacción simple
Hemos visto que el sistema se adapta automáticamente a la situación de la red y
ofrece los medios necesarios para efectuar los cambios pertinentes. Sin embargo,
siempre habrá situaciones en las que el usuario crea que debe ejecutar una acción o
un proceso, independientemente del estado de la red, bien porque tenga información
privilegiada de la red, o bien porque lo vea oportuno. Es por eso que se ha facilitado
un menú desplegable, que permite llevar a cabo estas acciones de forma unilateral,
independientemente del sistema inteligente. Para ello pulse en el botón Herramientas,
que abrirá un pequeño menú, que permite interactuar como se ha mencionado.
Ilustración 10: Menú Herramientas
Al accionar este menú, se desactivarán automáticamente los mensajes del sistema
inteligente, relacionados con él. La utilización de este menú está restringida a los
usuarios de más alto nivel, por razones de seguridad.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de WebCP2003
119
4 Administración del polling y obtención de medidas
El polling se define individualmente para cada dispositivo CP2003 conectado a la
red. Para ello podremos acceder desde la pantalla principal a cada uno de los
dispositivos conectados y establecer que medidas se quieren tomar. Una vez
hayamos terminado de seleccionar las medidas que queremos tomar sobre el
dispositivo, el sistema habrá detectado que ha habido algún cambio en el polling y
ofrecerá la posibilidad de guardar los cambios o por contrario, volver al estado inicial
del servidor.
Ilustración 11: Modificando el polling
En el ejemplo de arriba estamos añadiendo la medida VST sobre el dispositivo 0xA5.
En general, si decidimos guardar el polling, nos devolverá a la pantalla principal,
desde la que podremos acceder de nuevo a otro dispositivo sobre el que queramos
tomar medidas, en caso de necesitar observar mediciones de más de un dispositivo.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de WebCP2003
120
De esta forma vamos a ir definiendo el polling. Cuando hayamos terminado de
concretar las medidas que queremos incluir en el polling nos encontraremos en la
página principal con el siguiente aviso en forma de mensaje.
Ilustración 12: Modificando el polling II
Pulsamos en Actualizar, y el servidor RemModbus, cambiará su lista de polling. Por
último, es posible que sea necesario arrancar el proceso en el servidor, dependiendo
de si estuviera previamente funcionando o no. Para cualquiera de los casos se
mostrará un mensaje del estilo del aviso de la siguiente ilustración.
Ilustración 13: Start/stop polling
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de WebCP2003
121
5 Administración de usuarios
Al sistema de administración de usuarios sólo podrán acceder los usuarios de nivel
más alto. Para ello se dispondrá de un acceso por medio de mensaje típico de la
aplicación, y de otro por medio del desplegable Herramientas. Este apartado nos
permitirá tanto ver los usuarios del sistema como realizar modificaciones.
5.1 Editar usuario.
Para editar el nivel de acceso de un usuario, será necesario activar el modo edición
en la página de administración de usuarios, con el botón “Selección de niveles de
usuario”
Ilustración 14: Cambiando nivel de usuario
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de WebCP2003
122
Esta acción nos devolverá a la misma página anterior, pero preparada para editar.
Seleccionamos el usuario que queremos modificar, y pulsamos en “Cambiar Nivel”.
En el ejemplo vemos como hemos cambiado el nivel del usuario Michael Scofield a
Owner.
Ilustración 15: Modificando usuarios
5.2 Borrar usuario
El método a seguir para eliminar un usuario, es el mismo que para editarlo: en caso
de ser necesario activar el modo borrar, seleccionar el usuario a borrar y pulsar en
“Borrar Usuario”.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de WebCP2003
123
5.3 Añadir usuario
Los usuarios se añaden por medio del menú desplegable “Añadir Usuarios” de la
página de administración de usuarios, que se mantendrá desplegado hasta que
terminemos de añadir usuarios y volvamos a plegarlo.
Ilustración 16: Añadiendo usuarios
Se introducen los parámetros requeridos y se añade pulsando el botón.
Ilustración 17: Usuario añadido
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de RemCP2003
124
Capítulo 4 MANUAL DE REMCP2003
Ilustración 18: Conexión a RemModbus
Lo primero que se muestra en la aplicación es la ventana de conexión a RemModbus.
Introducimos usuario, contraseña y la dirección en la que reside la aplicación, y
pulsamos sobre el botón de conexión. La aplicación ofrece dos modos de actuación
según en que pestaña nos encontremos. La pestaña inicial nos permite conocer la
situación actual de un determinado valor.
Ilustración 19: RemCP2003. Toma de medidas
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de RemCP2003
125
En la ilustración de la página anterior hemos tomado la medida de voltaje VFR sobre
el dispositivo con dirección 0x03 y hemos obtenido un resultado de 222 V.
Ilustración 20: RemCP2003. Avanzado
La segunda pestaña nos permite actuar como administrador de cualquier red Modbus
introduciendo una trama arbitraria en la red. Para crear la trama se añade Byte a Byte
en hexadecimal. No se ofrece cálculo de CRC pero si RemModbus detecta que no
tiene CRC, lo añadirá él mismo. Vemos como se ha enviado la trama aleatoria 0x330x33-0x33-0x33-0x33-0x33- la cual lógicamente no ha obtenido respuesta como se
refleja abajo.
Recordemos que RemCP2003 sólo funciona con la modalidad DAT_ABS de
RemModbus por lo que si el servidor está ocupado, la aplicación quedará esperando
a que termine el servidor, para recibir una respuesta a la petición que se haga.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo I Manuales de usuario. Manual de RemBridge
126
Capítulo 5 MANUAL DE REMBRIDGE
El funcionamiento es muy sencillo ya que tan solo consiste en conectarse a
RemModbus con una ventana de conexión [Ilustración 18: Conexión a
RemModbus] y posteriormente en conectarse a un puerto COM del ordenador en el
que reside la aplicación [Ilustración 4: Configuración de la conexión Modbus], a
través del cual capturaremos el tráfico y lo enviaremos al servidor, que tratará las
tramas como cualquier otro programa RemModbus.
Ilustración 21: RemBridge
Permaneceremos conectados hasta que cerremos el la ventana anterior. Es importante
que se haya creado un puente entre dos puertos virtuales. En el caso anterior debe de
existir otro puerto virtual conectado a COM4, al que se conectaran las aplicaciones
típicas Modbus.
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.
Anexo 2 CP200X Communication Protocol. Manual de RemBridge
127
ANEXO 2 CP200X
COMMUNICATION PROTOCOL
Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.