Modbus Java

.
Resumen
Captulo 1 RESUMEN
El proyecto Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementacin Web y Java del sistema para CP2003, tiene el objetivo final de desarrollar una aplicacin que lea e interprete las medidas del dispositivo CP2003 por medio de Internet. Este dispositivo tiene la funcionalidad general de tomar medidas e informacin de una red elctrica, 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 categoras o subproyectos. El primero, correspondera a la aplicacin que sabe cmo comunicarse con el dispositivo (va Modbus), obtiene la informacin requerida de l y sabe como interpretarla, en otras palabras una especie de controlador. El segundo va a consistir en el desarrollo de un mtodo que nos permita abstraernos de los detalles de la comunicacin Internet. Esta decisin ha derivado en el diseo y programacin de una aplicacin 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 aplicacin del servidor sobre la red Modbus. Esta herramienta no implementar ningn 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. Implementacin Web y Java del sistema para CP2003.
. Resumen
ii
Los resultados finales obtenidos son:
RemModbus ser una aplicacin que de forma remota y local, administra una red Modbus cualquiera. Adems 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 diseado para obtener de forma remota informacin de uno o varios dispositivos CP2003
RemCP2003 ser un programa Java para la ejecucin de consultas definidas sobre un CP2003. Las tramas se interpretarn.
RemBridge permitir la creacin de una comunicacin entre una aplicacin Modbus cualquiera y un dispositivo Modbus, a travs de Internet, usado la tecnologa RemModbus desarrollada anteriormente. En la parte del cliente, se ejecutar RemBridge, el cual, se comunicar con un puerto COM virtual. Una aplicacin 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 comunicacin real.
. Abstract
iii
Captulo 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.
. 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.
. ndice
NDICE
Memoria ..................................................................................................................... 1 Captulo 1

1 2
Introduccin....................................................................................... 2
Estado del arte.......................................................................................................... 3 Motivacin del proyecto ........................................................................................ 7

2.1 Modbus sobre TCP ..................................................................................................................7 2.2 Uso del CP2003.......................................................................................................................9
Motivacin 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
Identificacin de Necesidades............................................................................ 16
4.1 Objetivos ...............................................................................................................................16 4.2 Alcance de la aplicacin.........................................................................................................19 4.3 Tipologa de los usuarios .......................................................................................................20 4.4 Restricciones..........................................................................................................................21
5 6 7
Metodologa de desarrollo .................................................................................. 22 Recursos, herramientas y tecnologas empleadas ........................................... 23 Estudio de la arquitectura.................................................................................... 25
7.1 RemModbus y RemBridge ....................................................................................................25 7.2 RemCP2003 y WebCP2003 ..................................................................................................25 7.3 Arquitectura extendida de la aplicacin. ...............................................................................26
Captulo 2
1
RemModbus ..................................................................................... 27
Introduccin ........................................................................................................... 27
. ndice
vi
Diseo ..................................................................................................................... 28
2.1 Diseo de la Base de Datos....................................................................................................29 2.2 Diseo del protocolo RemModbus.........................................................................................30 2.2.1 Proceso de conexin y establecimiento de usuario:.............................................................32 2.2.2 Otras transacciones cliente servidor. Lgica de confirmaciones......................................33 2.2.3 Lista de transacciones.........................................................................................................34 2.3 Diseo de RemModbus Servidor...........................................................................................36 2.3.1 Lgica del enlace fsico con los puertos del protocolo Serie.................................................36 2.3.2 Lgica de conexin de equipos remotos...............................................................................37 2.3.3 Diseo de control de estado de la red..................................................................................37 2.3.4 Lgica de colas. ...................................................................................................................40 2.3.5 Lgica de la comunicacin Modbus....................................................................................42 2.3.6 Diseo de control de obtencin de respuestas.....................................................................43 2.3.7 Lgica del descubrimiento de dispositivos conectados a la red (Finding)...........................44 2.3.8 Lgica del polling. ..............................................................................................................45 2.3.9 Lgica de transmisin de tramas. CRC. .............................................................................46 2.4 Diseo de RemModbus Cliente .............................................................................................47
Programacin y pruebas ...................................................................................... 48

3.1 Programacin del acceso a la BBDD .....................................................................................51 3.2 Programacin del protocolo RemModbus..............................................................................52 3.3 Programacin de RemModbus Servidor................................................................................55 3.3.1 Programacin de gestin conexin con protocolo serie: Enlace.java ..................................56 3.3.2 Programacin de gestin de conexiones remotas................................................................56 3.3.3 Programacin de gestin de estado: Estado.java ................................................................58 3.3.4 Programacin de colas........................................................................................................60 3.3.5 Programacin de comunicacin Modbus y control de obtencin de respuestas. ................62 3.3.8 Programacin del CRC.......................................................................................................67 3.4 Programacin de RemModbus Cliente..................................................................................69
API RemModbus................................................................................................... 70
Captulo 3
1 2 3
WebCP2003, RemCP2003 & RemBridge...................................... 71
Introduccin ........................................................................................................... 71 Requerimientos funcionales ............................................................................... 72 Requerimientos no funcionales ......................................................................... 73
. ndice
vii
4 5 6 7
Modelo de dominio .............................................................................................. 73 Diagrama de casos de uso.................................................................................... 74 Descripcin de los casos de uso.......................................................................... 75 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 9
RemCP2003............................................................................................................. 93 RemBridge.............................................................................................................. 94
Captulo 4
1 2 3 4 5
Resultados/Experimentos .............................................................. 95
RemModbus........................................................................................................... 95 WebCP2003............................................................................................................. 96 RemCP2003............................................................................................................. 96 RemBridge.............................................................................................................. 96 Experimentos.......................................................................................................... 97
Captulo 5 Captulo 6 Captulo 7

1 2 3
Conclusiones.................................................................................... 98 Futuros desarrollos....................................................................... 100 Estudio Econmico ....................................................................... 103
Planificacin previa ............................................................................................ 103 Uso real aproximado del tiempo invertido en el proyecto .......................... 104 Valoracin econmica ........................................................................................ 104
Bibliografa............................................................................................................ 105 Anexo I Manuales de usuario.............................................................................. 107 Captulo 1 API de RemModbus ...................................................................... 108
pfc_dsm.RemModbus Class SerialPort .................................................................. 108

. ndice
viii
Captulo 2 Captulo 3
1 2 3 4 5
Manual de RemModbus ............................................................... 112 Manual de WebCP2003 ................................................................ 116
Entrar en la aplicacin............................................................................................. 116 Sistema inteligente de interaccin........................................................................... 117 Interaccin simple ................................................................................................... 118 Administracin del polling y obtencin de medidas............................................... 119 Administracin de usuarios..................................................................................... 121
5.1 Editar usuario. ....................................................................................................................121 5.2 Borrar usuario .....................................................................................................................122 5.3 Aadir usuario ....................................................................................................................123
Captulo 4 Captulo 5
Manual de RemCP2003 ................................................................ 124 Manual de RemBridge.................................................................. 126
Anexo 2 CP200X Communication Protocol...................................................... 127
Memoria. ndice
MEMORIA
Memoria. Introduccin
Captulo 1 INTRODUCCIN
En la introduccin se van a estudiar tanto las soluciones alternativas a ciertas partes del proyecto basadas en otros trabajos previos o en otras tecnologas existentes, como las soluciones tomadas por el equipo de desarrollo. Se recomienda la lectura del resumen ofrecido anteriormente, para tener una visin general del proyecto y facilitar la comprensin de ste.
Como ejemplo, hemos visto anteriormente que uno de los pilares sobre los que se fundamenta este proyecto, consiste en el desarrollo e implementacin de un sistema que permite la comunicacin de cualquier aplicacin con la red Modbus. Aqu veremos por qu este punto es interesante y por qu se ha decidido implantar.
Ms adelante veremos los objetivos a alcanzar, con una breve descripcin, la metodologa de desarrollo del proyecto, sus fases, las herramientas, tecnologas y recursos que se han utilizado durante todo el ciclo de desarrollo e implementacin, etc.
En general durante la introduccin, distinguiremos entre las dos grandes partes del proyecto:
1. Temas relacionados con Modbus sobre TCP y su programacin. 2. Temas relacionados con el CP2003 y su uso remoto.
1 Estado del arte
Se establecer el entorno tecnolgico anterior al desarrollo del proyecto, desarrollando adems 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, cmo funciona y para qu se utiliza.
El protocolo Modbus es un protocolo abierto, lo que significa que puede ser utilizado gratuitamente por los desarrolladores. Aprovechndose de esto y de su sencillo diseo y versatilidad, Modbus se ha convertido desde su creacin en 1979 en el estndar de facto de entornos industriales, siendo utilizado para la comunicacin entre seales de instrumentacin 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 aplicacin Modbus en el modelo OSI, vamos a ver que el protocolo se acomoda en dos niveles,
Nivel de aplicacin (aplication layer), donde trabajaran los programas que utilizan los dispositivos e interpretan los datos de dichos instrumentos. (Ej: Windmill, Hyperterminal, etc.).
Nivel de protocolo (data-link layer), donde se localizara el intercambio de tramas bsicas del protocolo Modbus.
NIVELES OSI 7 6 5 4 3 2 1 Aplicacin Presentacin Sesin Transporte Red Enlace Fsico SI NO NO NO NO SI SI
APLICACIN MODBUS
Protocolo de aplicacin
Tramas Modbus 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 nmero de esclavo que se utiliza a modo de direccin. Modbus permite ver a cada dispositivo conectado como un banco de registros contiguos. Cada registro tiene una direccin de 16 bits dentro del rango 0x0000 a 0xFFFF, y tiene un tamao. Dependiendo de cada dispositivo, almacenar un determinado tipo de informacin (en el caso del CP2003, tensin, intensidad, etc.) o tendr una determinada funcin (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 ms significativo es enviado primero, luego a la hora de transmitir una cantidad mayor que un Byte, los 8 primeros bits se enviarn antes (Por ejemplo, 0x1F4E ser enviado como 0x1F 0x4E).
Como medio fsico de transmisin, 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 extensin bidireccional de RS232 para entornos industriales), mientras que RS485, adems de permitir distancias mas largas, puede ser utilizado para redes multipunto utilizando el
paradigma Maestro-Esclavo anteriormente mencionado. Lgicamente, el medio de transmisin ms utilizado, teniendo en cuenta esta informacin es RS485.
La comunicacin se basa en el paradigma Request-Response, de lo que se denomina comnmente PDU (Protocol Data Unit). El protocolo permite mediante tramas, consultar o actualizar el valor de dichos registros. La trama de peticin 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 peticin obtiene solo una trama de respuesta, a no ser que haya un error de trama, en cuyo caso no se obtiene ningn tipo de respuesta.
Figura 2: Comunicacin Modbus
continuacin
se
muestra
una
representacin
sencilla
de
una
trama
Modbus:
ID 1 Byte
CMD 1 Byte
INFO n Bytes
CRC 2 Bytes
Figura 3: Trama Modbus RTU o
ID (1Byte) es el nmero de esclavo, que hace las veces de direccin.
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
dispositivo, y programar su direccin adecuadamente. Se permite direccionar hasta un mximo de 63 esclavos con RS485.
o
CMD (1Byte) es el tipo de orden enviado al esclavo. Hay dos tipos
bsicos de rdenes: Lectura/Escritura de/en los registros del esclavo y rdenes de control (reset, start/stop, etc.)
Figura 4: Comandos Modbus
INFO (nBytes) definido anteriormente como PDU, contiene la
informacin necesaria para la ejecucin de la orden indicada en CMD. Esta puede estar organizada en direccin del primer byte, y nmero de bytes a escribir o leer en caso de Lectura/Escritura o podran ser cdigos de subfunciones para el caso de ordenes de control.
CRC (2Bytes) Mecanismo de control de errores de transmisin (cyclic
redundancy check)
2 Motivacin del proyecto

2.1 Modbus sobre TCP
Existe un mtodo para acceder remotamente a la red Modbus va TCP/IP: el protocolo Modbus/TCP. ste no es ms que una extensin de Modbus, introducida por Schneider Automation, que encapsula el las tramas Modbus sobre tramas TCP para permitir su envo y recepcin a travs 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 continuacin se va a describir como se encapsulara en Modbus/TCP una trama Modbus de peticin o respuesta. Estas tramas poseen una cabecera compuesta por 6 Bytes divididas en tres campos, como se aprecia en el grfico.
TRAMA MODBUS
ID
CMD
INFO
CRC
ID TRANS
ID DE PROT
LONGITUD
TRAMA MODBUS
TRAMA MODBUS/TCP
Figura 5: Trama Modbus RTU encapsulada sobre Modbus/TCP
Posicin del Byte y su significado Byte 0 - Identificador de transaccin. Copiado por el servidor. Normalmente 0. Byte 1 - Identificador de transaccin. 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). Nmero de bytes siguientes. Byte 6 - Identificador de unidad (ID), previamente direccin esclavo. Byte 7 - Cdigo de funcin Modbus (CMD). Byte 8+ - Los datos necesarios.
Las soluciones comerciales que utilizan Modbus/TCP ofrecen dos tipos de arquitectura en funcin de en que lado se deseen situar los dispositivos maestros, si en la parte Serie o en la parte TCP. La arquitectura ms utilizada es aquella en la que los dispositivos maestros, es decir, los dispositivos que solicitan la informacin de los esclavos, estn en la parte TCP.
Modbus Master 1 (Cliente)
INTERNET INTRANET Modbus TCP
Esclavo 1 RS232 Modbus RTU (Maestro)
TCP/IP
(Servidor)
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 funcin 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 pginas Web que permite navegar a travs de los dispositivos de la red y mostrar el estado de sus registros como si estuviramos 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 caractersticas de un dispositivo concreto al que se conecte.
2.2 Uso del CP2003
El Multiconvertidor Programable CP200X es un equipo de la empresa espaola SACI, que recibe seales de energa de una red elctrica, las mide y procesa, y las enva a distancia mediante tres salidas de tipo analgico, 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 analgicas pueden ser configuradas para representar cualquiera de las variables medidas. Asimismo, las salidas digitales pueden representar o bien impulsos correspondientes a la energa consumida, o bien una seal de alarma sobre alguna de las variables medidas. SACI ofrece por medio de su pgina 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 Elctrica CP2003
Sistema de Control
Figura 7: Conexin bsica del CP200X
10
Datos de informacin tcnica: 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 bsicas, de la forma siguiente:
Ecuacin 1: Ecuaciones de clculo de medidas
Vi2,j I = I i2, j S = P 2 + Q 2 Vi = 32 i i i i 32
(V P=
i
i, j
* Ii , j )
32
Qi =
((V
i, j
8) * I i , j ) 32
Para la medida de frecuencia se dispone del temporizador programable del micro, que mide el periodo de la seal de red, entre dos pasos por cero sucesivos. La determinacin 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 configuracin del equipo, tanto en lo que se refiere a datos de usuario, como a los de calibracin del equipo. El multiconvertidor adems ofrece tres tipos de salida: Serie: La salida de comunicaciones, puede ser bien RS232, o RS485. No esta aislada respecto de la analgica S2, pero si del resto. Analgicas: Las salidas analgicas se encuentran asimismo aisladas del resto de circuitos, y disponen de una fuente de alimentacin individual mediante convertidores CC/CC. Digitales: Dos salidas digitales a base de rels se pueden utilizar, para envo de pulsos de energa a distancia, o como seales de contactos maniobrados desde el PLC o PC.
11
3 Motivacin del proyecto

3.1 Desarrollo de un entorno para el desarrollo de aplicaciones remotas Modbus
Este primer apartado justificara la creacin de un sistema que facilite el desarrollo de aplicaciones remotas en Java, para permitir el acceso a la red Modbus a travs de Internet o intranet.
La motivacin ms importante de esta primera parte del proyecto es que va a permitir a futuros usuarios desarrollar fcilmente aplicaciones que trabajen sobre redes o dispositivos Modbus, sin tener la necesidad de utilizar una solucin 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 tpico con Microsoft Windows y un puerto serie tpico RS232 RS485, para que se conecte a la red y haga las veces de servidor, o de gateway.
Muy importante es tambin, que no solo se pretende establecer una comunicacin, sino que se pretende desarrollar todo un entorno capacitado para recolectar informacin de la red, y traspasar las fronteras del protocolo ofreciendo servicios de control de acceso y de control y recuperacin de errores, cosa que un protocolo sin estados y sin capa OSI de transporte como es Modbus, no posee.
Adems se pretende facilitar la labor de los programadores, evitndoles el estudio del protocolo ya desarrollado Modbus/TCP, descrito con anterioridad, que sera necesario para desarrollar cualquier aplicacin remota. Muchos ingenieros y desarrolladores de software industrial, no estn familiarizados en comunicaciones
12
TCP/IP y ven cmo sus trabajos para la administracin de estas redes tpicamente industriales, tienen que quedarse limitados al entorno fsico 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 diseador o programador de todo el entorno de comunicacin de manera que no tenga que preocuparse por ningn tema de protocolos de Internet. Tambin podremos asegurar que estos podrn abstraerse de trabajar a nivel de puertos serie. Esto se suele llevar a cabo con una librera de comunicacin serie de Java, de la que no hay demasiada documentacin, adems de no ser intuitiva y no todas sus utilidades funcionan correctamente en todos los entornos. Para facilitar aun ms 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 fcil como pueda ser utilizar cualquier otra librera 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 bsicas de nuestra aplicacin podrn recrear en su ordenador el funcionamiento de una transaccin tpica Modbus. Esto significa que se podrn 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 administracin de red, o incluso aplicaciones Web como las que ofrecen empresas como Lantronix1 o Intellicom2 en sus gateways Modbus Modbus/TCP.
http://www.lantronix.com/ http://www.intellicom.se/
13
3.2 Desarrollo de aplicaciones Modbus remotas
Una vez justificado el desarrollo de una formula capaz de facilitar el acceso remoto y la programacin de aplicaciones remotas, debemos estudiar en que medida ofrecen ventajas las aplicaciones remotas para redes y dispositivos Modbus.
La ms evidente ventaja del acceso remoto, es que no es necesario un desplazamiento fsico hasta donde est implementada la red, por lo que inmediatamente se reducirn 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.
La gestin de sistemas distribuidos se hace ms sencilla usando las tecnologas de Internet disponibles, por lo tanto conseguiremos mejorar este aspecto.
Esta tecnologa nos brinda tambin la posibilidad de mejorar el servicio a los clientes. Los tiempos de respuesta se reducirn y podrn desarrollarse nuevos servicios que carecan de sentido en un mbito meramente local.
Por otra parte podremos aprovechar infraestructuras serie y TCP ya creadas sin necesidad de modificarlas, y continuar ofreciendo conexiones multipunto.
Mediante un Standard de comunicacin universal como es TCP/IP y un protocolo pblico Modbus, obtenemos una red realmente abierta, para un intercambio y proceso de datos.
14
Se ofrece la posibilidad de realizar conexiones remotas con equipos de campo, pero no olvidemos que tambin 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 porttiles esta dejando de incorporar rpida y progresivamente las conexiones serie tipo RS232, que se venan incluyendo sus productos. La empresa hp (http://www.hp.com) por ejemplo, ya no ofrece este tipo de conexin en sus ltimos porttiles, y es muy comn 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 mayora equipos de campo trabajan bajo protocolos serie, ms concretamente, Modbus. Todo esto, e incluyendo la incorporacin de tecnologas inalmbricas de acceso a redes Ethernet (WiFi), convierten este tipo de aplicaciones, no solo en una solucin a la falta de puertos COM en los porttiles, sino una herramienta cmoda de conexin a redes Modbus sin necesidad de cables.
Cliente #1 TCP/IP
Servidor TCP/IP Maestro Modbus
Esclavo #1 Modbus
RS485 Esclavo #2 Modbus
Cliente #2 TCP/IP
Figura 8: Ventajas wireless aplicadas al mundo TCP - Modbus
15
3.3 Controlador remoto del CP2003
Dos puntos pueden resumir la motivacin 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 energticas, sobre una red elctrica 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, adems de ser de pago, no proporcionara acceso remoto.
2. Necesidad de probar la herramienta de desarrollo: Desde un punto de

vista ms personal, esto representa una buena oportunidad para probar la potencia y sencillez del sistema de desarrollo creado con anterioridad, en una aplicacin 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 tpico en el que un control de energa de la red elctrica 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 das fros o de invierno. El dueo del hotel supone que si mantiene encendido el aire en estas circunstancias, el consumo ser menor que durante el verano o los das calurosos, ya que mucha gente no har uso de l. Sin embargo tambin sabe que mantener encendido este servicio para todo el hotel supondra 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 llevaran a cabo si el dueo del hotel tuviera que ir al lugar donde esta conectado a la red elctrica el dispositivo y tomar nota de los datos. El acceso remoto va a facilitar sustancialmente las operaciones administrativas de este tipo.
16
4 Identificacin 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 aplicacin 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: Cooperacin entre productos finales
17
4.1.2 Objetivos de RemModbus
Conseguir la comunicacin bsica Modbus: intercambio de PDUs. Permitir, mediante una instanciacin muy sencilla, el acceso de cualquier aplicacin Modbus a la red, de forma remota. Permitir acceso mltiple a la aplicacin. Aplicacin escalable. Disear una arquitectura modular que permita incorporar fcilmente varios dispositivos a la red. Implementar esa arquitectura y permitir comunicar con varios dispositivos Desarrollar una API que facilite la utilizacin de RemModbus. Trasladar a nuestra aplicacin 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 implementacin de un polling de tramas Modbus sobre la red. Permitir el acceso a los resultados de dicho polling. Utilidad de bsqueda automtica de dispositivos Modbus conectados a la red. Ofrecer cierto reconocimiento y recuperacin de fallos, necesario para aplicaciones remotas, y no ofrecido por Modbus. Por ejemplo, solucionar la colisin que se provocara si se ejecutan dos peticiones al mismo tiempo o reponerse ante una situacin de no respuesta. Ofrecer informacin sobre el estado de la red, o mejor dicho del sistema que administra la red (RemModbus).
18
4.1.3 Objetivos de RemCP2003
Entendamos provisionalmente como RemCP2003 a cualquier aplicacin que haga uso de la red de forma remota y en concreto del CP2003, utilizando RemModbus.
Creacin del programa que permita, instanciando solo una clase, a cualquier aplicacin 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. Creacin de una aplicacin Java RemCP2003. Creacin de un Web Service RemCP2003. Administracin de usuarios. Implementacin de competencias segn nivel de usuario. Implementar la comunicacin bsica request-response. Dar soporte al trabajo sobre varios equipos CP2003. Administracin de polling en funcin de las necesidades de cada dispositivo. Administracin del sistema (RemModbus) que maneja la red Modbus, y por tanto administracin de la misma Implementar la mayor cantidad de recursos disponibles en RemModbus para conseguir una aplicacin slida y evaluar su potencia y versatilidad.
19
4.2 Alcance de la aplicacin
Se desarrollar en primer lugar la herramienta RemModbus con las funcionalidades necesarias para dar soporte a los requerimientos de una aplicacin remota que necesita ser desarrollada. En el mbito de este proyecto esta aplicacin 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 utilizacin de la herramienta (concretamente sobre CP2003) y en lugar de desarrollar una sola aplicacin que haga uso del mximo de funciones posibles, se van a desarrollar tres tipos de aplicaciones modulares que tendrn distintos objetivos.
De esta manera vamos a dividir lo que antes conocamos 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 aplicacin es permitir que cualquier programa ya desarrollado y preparado para trabajar slo en mbito local, pueda hacerlo de manera remota. Consistir en la aplicacin ms sencilla de todas a la hora de codificar, ya que solo tendremos que instanciar RemModbus y llamar a uno de sus mtodos.
20
2. RemCP2003: Mantendremos el nombre original para aquella aplicacin Java que permitir, en funcin del nivel de usuario, enviar o solo tramas definidas con anterioridad o adems 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 parmetros de funcionalidad de la red, conocer su estado, los dispositivos conectados, administrar el polling y administrar usuarios. Todo ello en funcin tambin del nivel de usuario.
4.3 Tipologa de los usuarios
A partir de la informacin 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 energa de una red elctrica, por ejemplo un gerente para tomar decisiones administrativas en funcin del consumo de una planta, o un analista interesado en estudiar las variaciones de ciertas medidas como voltaje o intensidad de un entorno elctrico.
Usuarios comunes: Cualquier persona que tenga contratado un plan elctrico y sospeche que podra ahorrar ms con otro ms barato, pero no sabe realmente cuanta energa 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.
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 versin Servidor, slo funciona en Microsoft Windows. El sistema se ha probado satisfactoriamente en XP SP2 y Vista.
BridgeModbus, al utilizar la misma tecnologa que RemModbus, slo 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, Contrasea: 3sfe617, nombre de la tabla de usuarios: w1092467_user).
Para un correcto funcionamiento de RemModbus y BridgeModbus, se deben instalar las libreras de comunicacin de Java en las carpetas correspondientes de la JRE.
Las entradas y salidas de RemModbus se efectuarn en forma de java.lang.String, que comnmente sern tramas Modbus con el siguiente formato: 0x01-0x04-0x04-0xb5-0x00-0x01
Dado que los PCs que implementan puertos COM, tpicamente funcionan sobre RS232, si se desea permitir la conexin de varios dispositivos se debe crear una red RS485. Para ello el laboratorio ofrece convertidores hardware RS232-RS485.
Para la ejecucin del Web Service de WebCP2003, se necesitar Apache Tomcat.
22
5 Metodologa de desarrollo
Mtodo incremental o evolutivo.
Como hemos venido estableciendo, este proyecto se divide en varias fases. Adems y como la mayora de los proyectos cada fase se divide a su vez en distintas subfases, que posiblemente estn formadas por distintas etapas. Se han estudiado varios mtodos existentes para ver cul es la arquitectura de metodologa que mejor se adapta a la que hemos utilizado para el desarrollo del proyecto. La que ms se aproxima es denominada mtodo 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 mnimos para poder codificar un primer modelo del ncleo del sistema sobre el que poder trabajar. Posteriormente se ha dividido
Fase 1 Fase 2 Fase n
en fases el proyecto estableciendo claramente sus las competencias que deba abordar, y se ha aplicado este modelo a cada una de esas fases, pudindose obtener de cada etapa un realizar un primer modelo del ncleo del sistema y codificarlo. Esto se adapta muy bien a nuestras necesidades ya que no tenamos certeza de cmo se desarrollara la aplicacin, ni cmo bamos a solucionar ciertos problemas de implantacin. Por otra parte el modelo evolutivo o incremental, se adapta muy bien a la programacin orientada a objetos, y dado que utilizamos Java para su desarrollo, parece ser de nuevo la mejor opcin.
23
6 Recursos, herramientas y tecnologas empleadas
Para el desarrollo de en Java se ha utilizado
o Java 2 Standard Edition (J2SE) como lenguaje de programacin. o NetBeans IDE 5.5.1 como entorno de programacin. o NetBeans GUI Builder para el desarrollo de interfaces grficas de
Java.Swing.
o Librera Java javax.comm para las comunicaciones serie. o NetBeans Java Runtime Environment (JRE) como entorno de
ejecucin.
o Notepad++ 4.5 para ediciones puntuales de cdigo.

VSPD XP4, para establecer una conexin 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 conexin, creacin y edicin de
tablas e informacin de mi BBDD
o MySQL Java Connector 5.1.6 para permitir a la aplicacin Java

conectarse a la BBDD e interactuar con ella. Para el diseo y planificacin de la aplicacin,
o Jude-UML 1.6.2 para la creacin 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 edicin de grficos
24
Se han utilizado varias tecnologas de comunicaciones
o TCP, Ethernet, 10/100BaseT o Serie, Modbus, RS485 o Osciloscopio para el estudio de seales RS232 y RS485.
Para la comunicacin Serie,
o CP2003 o PLCs y pupitre de mando para proporcionar mas funcionalidad al

CP2003
o Windmill comDebug y Hyperterminal para la captura e interpretacin

de tramas Modbus. Se han utilizado dos convertidores hardware,
o Convertidor USB Serial o Convertidor RS232 RS485

Se ha desarrollado tecnologa Web Service basada en Servlet y JSP
o Apache Tomcat para ejecutar el servidor Web o Adobe Macromedia Dreamweaver CS2 para la edicin de las pginas
JSP.
o Notepad++ 4.5 para ediciones puntuales de cdigo. o Adobe Photoshop CS2 para la creacin y edicin de imgenes.
25
7 Estudio de la arquitectura
7.1 RemModbus y RemBridge
Como con toda aplicacin Java se va a precisar de un entorno de ejecucin tipo JVM (Java Virtual Machine). Tambin 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 nmero de usuarios posible, se ha pensado que era ms til centrarse en Windows por encima de otros OS como Linux. Es por eso que se ha decidido utilizar la librera JavaX (Java Standard Extension) Java Communications, orientada a Windows. Es necesario disponer de un puerto serie fsico 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 aplicacin de administracin de puertos virtuales, solucionaran este problema (no se proporcionan). En caso de querer dar soporte a toda una red de dispositivos Modbus, ser necesario un convertidor de seal RS232-RS485 (proporcionado por la Universidad).
7.2 RemCP2003 y WebCP2003
Ser necesario un entorno de ejecucin 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. Lgicamente, es necesario al menos un CP2003.
26
7.3 Arquitectura extendida de la aplicacin.
Red Cliente 1 Servidor RemModbus RS232 Router Convertidor RS232/RS485 RS485 10/100BaseT TCP/IP Dispositivo Modbus CP2003 #1 RS485 Elctrica
CP2003 #2
Cliente 4 Cliente 2
WebCP2003 RemCP2003 Usando Cliente 3 RemModbus
Figura 10: Diseo ampliado de la arquitectura
Memoria. RemModbus
27
Captulo 2 REMMODBUS
1 Introduccin
En este captulo tiene como propsito centrarse en el diseo, fases y programacin 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 aplicacin 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 disear. Existen dos variantes, con diferentes representaciones numricas de los datos y pequeas diferencias en el control de trama. Modbus RTU es una representacin binaria compacta de los datos mientras que Modbus ASCII es una representacin 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 Cclica (CRC, 2 Bytes), sin embargo en ASCII se aade un carcter 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 continuacin 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 ms extendido, las aplicaciones se han orientado a este tipo de formato, por lo que NO se permite la comunicacin Modbus ASCII en este proyecto
Memoria. RemModbus
28
2 Diseo
RemModbus va a estar dividido en dos subprogramas, que funcionarn bajo una arquitectura Cliente/Servidor que se comunicarn entre ellos mediante un protocolo propio diseado expresamente para RemModbus.
El programa Servidor se encargar principalmente de recibir y validar las conexiones entrantes, as como de la transmisin serie de tramas y la administracin del estado de la red. Recordemos que el protocolo Modbus es un protocolo sin estados ni nivel de transporte. Esta aplicacin 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 utilizacin y el acceso a la informacin ofrecida por el Servidor, mediante el uso de sus mtodos y de forma totalmente transparente al usuario, en funcin de las necesidades del usuario.
Memoria. RemModbus
29
2.1 Diseo de la Base de Datos
Como veremos a continuacin no se precisa una lgica muy desarrollada para el diseo de este apartado ya que tan solo necesitaremos una tabla en la que podamos albergar un conjunto de usuarios, sus contraseas, y el nivel que tienen. No obstante se especificar aqu por si se requieren modificaciones posteriores.
Diseo lgico 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 PASS PERMISSION Ser el alias del usuario. Se definir como clave primaria. Guardar la contrasea del usuario. Nivel del usuario. A discrecin de los programadores finales
Definicin SQL de las tablas
CREATE TABLE w1092467_user ( NAME PASS PERMISSION VARCHAR (20) NOT NULL, VARCHAR (20) NOT NULL, VARCHAR (20),
PRIMARY KEY (NAME);
Memoria. RemModbus
30
2.2 Diseo del protocolo RemModbus
Se ha diseado un protocolo que se adapte perfectamente a las necesidades de comunicacin entre los programas Cliente y Servidor del paquete RemModbus. Esta comunicacin comnmente se iniciar por parte del cliente, que requerir algn tipo de accin por parte del servidor.
1. Trama de accin 3. Trama de confirmacin 2. Proceso
Cliente
Servidor
Figura 12: Protocolo RemModbus
En el ejemplo vemos como un cliente enva una trama RemModbus al servidor pidindole algn tipo de accin. Esta accin puede consistir desde un proceso complicado como el de conexin hasta una consulta puntual de un estado concreto de la red, o por supuesto una transmisin de una trama Modbus.
CABECERA
LONGITUD
DATOS
Figura 13: Trama RemModbus
A continuacin estudiaremos el diseo y la funcionalidad de las tramas RemModbus. El protocolo esta diseado 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 operacin ha tenido xito o para notificar del error. Esto nos ofrece la informacin necesaria para tener la posibilidad de implementar un sistema de deteccin y recuperacin de errores donde antes no se poda.
Memoria. RemModbus
31
Se permitirn cuatro tipos distintos de operacin en el servidor, en funcin del valor de CABECERA, que tendr un tamao de 4 Bytes. Si es de tipo: i. ii. CON, se estar iniciando un proceso de conexin. SYN, se esta enviando o solicitando informacin al servidor para mantener sincronizados tanto a cliente como a servidor. Las distintas subclases de las tramas de sincronizacin se abordarn en la parte de programacin de este mismo captulo iii. DAT, la informacin 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 modificacin 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 informacin necesaria para la operacin que se precise, ya sea en la parte del servidor como en la parte del cliente.
Memoria. RemModbus
32
2.2.1 Proceso de conexin y establecimiento de usuario:

Intercambio de tramas. Formato: CLIENTE (accin)
1. CON (usuario + contrasea) 0. Establecer conexin sobre puerto de escucha 0. Escuchando en el puerto de escucha well known
CABECERA (DATOS)
SERVIDOR (accin)
2. Validacin de usuario. 4. ACK_CON (puerto + nivel de usuario) 3. Clculo de Puerto
5. Se termina la conexin 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 envo de informacin: Lista de dispositivos conectados.
Figura 14: Establecimiento de conexin en el protocolo RemModbus
Para implementar un sistema que permita la conexin simultnea de varios usuarios a la red se ha optado por un sistema en el cual a cada conexin se le establece un puerto en el servidor, que adems nos servir de identificador. Para resolver el problema de cmo sabe el cliente que puertos estn libres en el servidor, utilizamos una pequea modificacin en el concepto de la conexin: el cliente inicia una conexin sobre un puerto well known (conocido de antemano) del servidor, sobre el que tiene la certeza que esta escuchando. A continuacin el servidor, tras hacer las validaciones oportunas de usuario (conexin a la BBDD y comprobar si es correcto), si todo ha funcionado bien, enviar una trama ACK_CON con el puerto asignado a la conexin, y el nivel del usuario validado, obtenido de la base de datos. Es decir, se cerrar la conexin sobre el puerto de escucha, y ser el servidor el que inicie la conexin sobre el cliente. En caso de que la validacin de usuario no sea positiva, se enviar una trama NACK, y no se seguira con el proceso. Posteriormente el servidor volver a enviar una trama por la nueva conexin. La trama ser en este caso de tipo ACK_DAT y contendr la ltima actualizacin de la lista de dispositivos conectados.
Memoria. RemModbus
33
2.2.2 Otras transacciones cliente servidor. Lgica de confirmaciones.
Despus de comprender el funcionamiento de la lgica de conexin 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 fcil de entender como veremos ahora, sino que tambin es fcil de programar y utilizar, como veremos mas adelante.
Toda la lista de transacciones que veremos ms adelante sigue siempre la misma lgica, basada en la trama de confirmacin recibida.
1. CAB (DATOS) 0. Realizar operacin de tipo CAB en el Servidor 1. ACK_CAB (void) 2. Procesar operacin de tipo CAB en el Servidor
1. CAB (DATOS) 0. Realizar operacin de tipo CAB en el Servidor 1. ACK_DAT (DATOS) 2. Procesar operacin de tipo CAB en el Servidor
1. CAB (DATOS) 0. Realizar operacin de tipo CAB en el Servidor 3. NACK (void) o NACK_DAT (DATOS) 2. Procesar operacin de tipo CAB en el Servidor
Figura 15: Lgica de confirmaciones del protocolo RemModbus
Si la operacin en el servidor ha sido satisfactoria, se enviar una trama de confirmacin ACK_CAB (donde CAB es el tipo de trama enviada originalmente) en caso de que no se necesite informacin adicional o ACK_DAT, en caso contrario. Si la operacin no ha podido llevarse a cabo por alguna razn, se transmite una trama de tipo NACK, o NACK_DAT, siguiendo la misma lgica.
Memoria. RemModbus
34
2.2.3 Lista de transacciones
Tipo CON: (transaccin vista con anterioridad) CON + Usuario y Contrasea. 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 conexin. SYN_FIN: Devuelve la ltima revisin de los dispositivos conectados. SYN_FINON: Arranca el proceso de bsqueda de dispositivos. Devuelve el tiempo estimado para la finalizacin 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 ocupacin, o NACK si ya est libre.
Memoria. RemModbus
35
Tipo DAT: DAT + trama: Enva 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 bsqueda de dispositivos, se cancela el envo a la red Modbus y se devuelve NACK + ETA (Estimated Time of Arrival). DAT_ABS: + trama: Funciona de la misma forma que DAT a excepcin de que si hay un proceso funcionando, la peticin se encola y el cliente debe esperar su turno. Una vez enviada la trama no se puede cancelar la ejecucin 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, contrasea y nivel de usuario: Crea un usuario con los parmetros indicados.
Memoria. RemModbus
36
2.3 Diseo de RemModbus Servidor
Esta versin del paquete RemModbus har de representante del dispositivo maestro que desee interactuar con la aplicacin. 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 seal RS232RS485 como los que ofrece el laboratorio de la universidad. La aplicacin tiene tres partes muy bien diferenciadas, la primera, de acceso a los puertos serie del ordenador, y a la informacin 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 Lgica del enlace fsico con los puertos del protocolo Serie.
Diagrama 1: Enlace a puertos serie
Memoria. RemModbus
37
2.3.2 Lgica de conexin de equipos remotos
Diagrama 2: Procesador de conexiones entrantes
2.3.3 Diseo 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 informacin. Adelantamos que el nombre de esta clase va a ser Estado.java. Es imperativo para el correcto funcionamiento de la aplicacin 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 acudirn otros procesos y programas para realizar sus operaciones. A partir de ahora conviene distinguir entre conexin o uso de la red (Modbus), que ser interpretado como uso fsico del RS232 o RS485 y conexin y uso del sistema, entendiendo por sistema RemModbus. Empecemos por establecer a continuacin cuales sern las competencias de esta clase.
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.
Administracin del polling. Saber en todo momento si,
o Hay intencin de hacer polling, aunque no se este ejecutando porque

este otro proceso ejecutndose.
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
Administracin de usuarios. Saber en todo momento,
o Que usuarios estn conectados y a travs de que puerto. o Cuales de ellos desean transmitir. o Ofrecer desconexin.
Administracin de cola de acceso a la red Modbus. Hay que considerar,
o No todos los dispositivos pueden transmitir. Hay que desarrollar un

mtodo de acceso a la red.
o Ofrecer mtodos para sumarse a la cola.
Memoria. RemModbus
39
Administracin de los dispositivos conectados
o Ofrecer un sistema comn 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 estn conectados. o Tiempo estimado para que termine el proceso de finding
(descubrimiento)
o Posibilidad de introducir manualmente los dispositivos
Informacin y actividades relacionadas con el enlace a la red Modbus.
o Obtencin de canales fsicos de transmisin. o Mtodos de transmisin y recepcin 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 conexin 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.
Memoria. RemModbus
40
2.3.4 Lgica de colas.
Como Modbus no ofrece mecanismo control de envo, ni de acceso a la red, ni de recuperacin y retransmisin de tramas, tenemos que buscar una solucin para evitar el problema que se plantea ante la situacin 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 simultneamente, con un ejemplo.
Usuario #1
Dispositivo #1
RS485
Usuario #2
Dispositivo #2
Figura 16: Red Modbus
Hiptesis: El usuario #1 (u1) transmite una trama 0x01-0x01-0x01 a la que en

condiciones normales el dispositivo #1 (d1) contestara 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) contestara 0x22-0x22-0x22.
[1] Supongamos que u1 transmite e inmediatamente lo hace u2. De cara a d1 y d2

se recibira 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 recibirn 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 despus de que d1 reconociera la trama, con lo que d2 tambin la reconoce. Por lo tanto tenemos otra colisin formada por las respuestas, por ejemplo 0x11-0x22-0x11-0x11-0x22-0x22. Los usuarios no podrn interpretar la respuesta. Adems quin recibe la trama? u1, u2, los dos o ninguno?
Memoria. RemModbus
41
Adems 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 informacin puede viajar en un sentido o en otro, pero no al mismo tiempo) por lo que debemos evitar esta situacin en la solucin 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 tpica 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 quin 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 transmisin modular ya transmitida debe terminar su ejecucin y esperar a la respuesta de la red. R03 El proceso de descubrimiento de dispositivos, se considera una accin de actualizacin 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 continuacin veremos su aplicacin en los mtodos que acceden a la red: Comunicacin Modbus, Descubrimiento de dispositivos y Polling
Memoria. RemModbus
42
2.3.5 Lgica de la comunicacin Modbus.
Diagrama 3: Comunicacin Modbus
Recordemos que cada trama Modbus transmitida obtiene una o ninguna respuesta en funcin de si ha sido reconocida y aceptada por el equipo Modbus o no. Este diagrama muestra tambin la implicacin del cliente, desde la recepcin de una trama DAT enviada por l, hasta el envo de la respuesta obtenida de la red. Ntese adems la implantacin de la lgica de la diferencia entre DAT y DAT_ABS explicada con anterioridad. Hay que destacar tambin la implicacin del sistema de colas para el usuario, recordemos, FIFO.
Memoria. RemModbus
43
2.3.6 Diseo de control de obtencin de respuestas.
Estudiando el diagrama anterior observamos que la finalizacin de la aplicacin, depende de que la red conteste a la trama, pues el programa quedara bloqueado en Recibir trama hasta que haya respuesta. Esto se debe a la implementacin 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 ledo la trama, supongamos que hubo un error y actuemos en consecuencia. Esto se conseguir imponiendo un timeout a la instruccin 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.
Memoria. RemModbus
44
2.3.7 Lgica del descubrimiento de dispositivos conectados a la red (Finding).
Vamos a definir el proceso de finding como una actualizacin 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 ningn usuario o proceso hasta su correcta terminacin.
Diagrama 5: Finding
Memoria. RemModbus
45
2.3.8 Lgica 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 definicin. La solucin 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 lgico cualquier transaccin o proceso se ejecutar antes que cualquier transaccin de polling respetando R04. Adems aadimos 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 transaccin, debe ser reactivado al terminar dicho proceso o transaccin.
Diagrama 6: Polling
Memoria. RemModbus
46
2.3.9 Lgica de transmisin de tramas. CRC.
Hemos visto como generbamos un cuello de botella para el acceso a la red y luego invocbamos al envo y recepcin 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 cclica. Se ha de desarrollar una funcin que calcule y aada este CRC al final de cada trama. Esta funcin debe de estar preparada para el formato de datos utilizado por el sistema. Adems hay que tener en cuenta que no consiste en un tpico CRC de 32 bits, sino que es de 16 bits.
Diagrama 7: Clculo del CRC
Memoria. RemModbus
47
2.4 Diseo de RemModbus Cliente
El objetivo del cliente se concentra en conectarse a la aplicacin servidor de RemModbus y hacer uso de sus funciones a travs del protocolo RemModbus detallado con anterioridad. Esta aplicacin deber ser instanciada por otra aplicacin 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 instanciacin resulte lo ms sencillo posible para el programador. Hay que sealar 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 instanciacin se debe poder permitir
Establecer una comunicacin Modbus. Consultar el protocolo Modbus para ver los distintos tipos de comunicacin (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 actualizacin). Obtener los equipos conectados de forma activa (forzar actualizacin). 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 aplicacin. Desconexin del usuario.
Memoria. RemModbus
48
3 Programacin y pruebas
Antes de comenzar a programar necesitamos instalar las libreras 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 instalacin suele dar problemas en funcin de a donde est apuntando realmente la JRE o la JDK, y de cul de ellas se est utilizando para la ejecucin. Se recomienda consultar la FAQ de la API de comunicaciones de Java [20]. Esta instalacin ser obligatoria para el equipo que desee utilizar tanto la versin servidor de RemModbus como mas adelante veremos, RemModbus.
mysql_connector tambin ser utilizado por el servidor RemModbus. Importar los paquetes necesarios.
Diagrama 8: Organizacin de RemModbus
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 lgica de las conexiones a la BBDD. Puesto que slo 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 recepcin y envo de datos a travs del puerto serie, se ha descubierto que no funcionaba correctamente en algunos casos puntuales, necesarios para desarrollar la aplicacin como estaba disado. 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 captulo se explicarn nicamente la finalidad o funcionamiento de las funciones o mtodos que, o bien no tengan un nombre intuitivo, o bien su desarrollo a la hora de programar tenga algn aspecto interesante. Tampoco se incluirn todas los mtodos en los diagramas o en los apartados.
Se ha tomado la decisin de estandarizar cualquier proceso de intercambio de datos entre programas y procesos, independientemente de cmo trabajen internamente. Adems se ha optado porque el intercambio de tramas Modbus sea el interpretado generalmente para estas redes. Es decir como suelen utilizarse lgicamente los datos de una trama Modbus.
Memoria. RemModbus
50
Requisitos no funcionales
NF01 Las comunicaciones entre programas y procesos se realizaran por medio de cadenas de caracteres, envindolas y recibindolas como objetos java.lang.String.
NF02 Elementos de una lista se enviarn separados por el carcter & o por el juego de caracteres --- en el caso de la conexin.
NF03 Las tramas sern enviadas y recibidas en todo el entorno RemModbus como agrupaciones de 16 bits e interpretadas como nmeros
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 carcter -.
NF05 La lgica de separacin de NF04 se har extensible a cualquier juego de elementos de una misma entidad lgica.
NF06 La aplicacin se desarrollara en J2SE.
NF07 Se usar MySQL para el almacenamiento.

Localizado en rhino.cscs.wmin.ac.uk/3sfe617
Memoria. RemModbus
51
3.1 Programacin del acceso a la BBDD 3.1.1 Diagrama de clases
Diagrama 9: Conexin a la base de datos
Se ha decido crear, una clase abstracta DAO que se encargue de almacenar la informacin 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
Memoria. RemModbus
52
3.2 Programacin del protocolo RemModbus
Para la utilizacin del protocolo se van a utilizar las herramientas que se han desarrollado para esta parte del proyecto. Estas estn alojadas en el paquete Inet [Diagrama 8: Organizacin 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 fcilmente a sus campos. A continuacin se muestra la parte del cdigo que codifica el tipo de tramas y el diagrama de clase correspondiente.
public static final int CON public static final int ACK_CON public static final int ACK_DAT public static final int DAT public static final int DAT_ABS public static final int SYN_POLON public static final int SYN_POLRUN public static final int SYN_FIN public static final int SYN_FINON public static final int SYN_POLDAT public static final int SYN_POL public static final int SYN_CON public static final int SYN_CAN public static final int SYN_ETA public static final int ACK_SYN public static final int NACK
= 29; = 19; = 39; = 2; = 1; = 49; = 48; = 46; = 44; = 47; = 45; = 41; = 42; = 43; = 59; = 90; //+trama Modbus. Con finding devuelve ETA //+trama Modbus. Se trans. tb con finding //Pregunta el estado del polling //StartStop polling de forma remota //pide la lista de ids //Start finding de forma remota //En DAT va la lista de polling //pide la lista de poll //desconecta al user (logout) //renuncia a la sig.trama respuesta //pide ETA //Ready+lista polling actual u otro
Memoria. RemModbus
53
public static final int NACK_DAT public static final int MAXDATA protected int tipo;
= 99; = Integer.MAX_VALUE;
//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.
Organizacin de mtodos:
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
Memoria. RemModbus
54
Estas dos clases nos van a permitir establecer los canales por los que vamos a enviar y recibir la informacin proveniente del protocolo RemModbus.
Gracias a este paquete, nos va a resultar muy sencilla la comunicacin con el protocolo Modbus. Lo primero que debemos hacer es crear los TramaInetIS y TramaInetOut de la forma siguiente
Socket in = new Socket() //creacin 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 mtodos 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();
Memoria. RemModbus
55
3.3 Programacin 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 trminos de programacin se refiere a crear un nuevo Enlace.java y un nuevo Server.java. Tambin podremos ejecutar el polling o el finding. Tambin podremos falsear el proceso de finding si conocemos de antemano las direcciones de los dispositivos conectados3.
Figura 17: RemModbus Servidor
No se ha implementado ningn mecanismo de deteccin 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 errtica.
Memoria. RemModbus
56
3.3.1 Programacin de gestin conexin con protocolo serie: Enlace.java
Diagrama 12: Enlace.java
Se solicita informacin del usuario, para establecer los parmetros de conexin a la red serie. Los parmetros pedidos son tales como puerto COM al que desea conectarse, velocidad de transmisin, bits de parada, control de flujo, bits de parada, etc. A continuacin crear la conexin4 utilizando la API javax.comm y establecer los canales de entrada y de salida tpicos.
3.3.2 Programacin de gestin 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 conexin aceptada.
Diagrama 13 Server.java
Al crearse una conexin serie, el puerto queda bloqueado no permitindose ms conexiones sobre l
Memoria. RemModbus
57
El servidor de conexiones entrantes est montado sobre un Thread, bloqueado dentro de un bucle infinito en la instruccin 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 funcin de los puertos que se estn utilizando. Esto significa que solo aceptaremos hasta 30 conexiones remotas. Si se llega al lmite se enva una IOException. Con ese puerto calculado y la direccin 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 conexin. Una vez creada, enva 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 acta en consecuencia tras interpretar el tipo de trama. Tpicamente llamara a una funcin u otra mandando en caso de ser necesario, una modificacin sobre Estado.java.
Memoria. RemModbus
58
3.3.3 Programacin de gestin 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 instanciacin de esta clase, que debe estar presente en todas las instancias que efecten una modificacin de estado5. Aprovechando esta situacin se aadirn los mtodos necesarios para la transmisin de tramas al puesto serie.
public static final int POLLING = 991; public static final int GETDIRECCIONES = 992; public static final int ACCESOMAESTRO = 993; private int acceso; private boolean onTCP; private boolean onModbus;
//Para determinar quien //esta accediendo a la //red Modbus actualmente //(sobre acceso)
//indica si esta conectado a red TCP //indica si esta conectado a red MDBS
//polling\\ private boolean polling = false; private ArrayList pollingList; //TRUE si hay intencion de polling. //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; private ArrayList usList; private User currentUserModbus; //el turno para varios users, etc //Lista de los usuarios conectados //Mantener user en poder del acceso.
private ArrayList modbusId;
//Lista de disp Modbus conectados //Se guardan sin 0x
Es completamente necesario que cualquier modificacin en el estado de la aplicacin, se vea
reflejado en la instancia nica de Estado.java.
Memoria. RemModbus
59
private boolean findingDone = true; private int findingProgress; private Enlace link; private Thread cuenta; private Timeout to;
//Cuando esta parado el finding //porcentaje completado finding //via de comunicacin con MODBUS.
//Modifican la variable que dice si //la red responde o no a la trama //Control de respuesta a trama
private boolean timeOver = true;
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; private Thread pllng;
//Polling
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 ms de 50 mtodos, vamos a pasar a explicar slo 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.
Memoria. RemModbus
60
3.3.4 Programacin de colas
Este proceso se basa en la misma forma de proceder que en el ejemplo anterior de peticin de progreso y ETA del finding. Los procesos que quieren transmitir, se aaden en una posicin determinada de una cola como se vio en el apartado de diseo. Los procesos que optarn a transmitir son una comunicacin 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();
- Comunicacin 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();
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 ms informacin, referirse a los comentarios del cdigo.
Memoria. RemModbus
62
3.3.5 Programacin de comunicacin Modbus y control de obtencin de respuestas.
El envo de tramas se har directamente sobre un mtodo de Estado.java enviarTrama(String trama) utilizando las herramientas mostradas, sin embargo la recepcin se har en un nuevo Thread ReceiveTrama.java
Diagrama 15: ReceiveTrama.java
Se ha establecido durante el diseo que para controlar la falta de respuesta de la red se deba de incorporar un timeout a una instruccin. Evidentemente eso no es posible en Java de forma directa, ni en ningn lenguaje de programacin. Empezaremos a manejar los parmetros necesarios en la ejecucin de ReceiveTrama.java desde la funcin 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 {/*ESPERAMOS*/} == false && tramaOutReady == false) //Timeout de la
Memoria. RemModbus
63
Para poder continuar la ejecucin 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); //trata de leer trama //en caso de leer algo estado.setTramaReceived(tramaReceived); estado.setTramaOutReady(true); //modificacion de tramaOutReady //modificacion de tramaOutReady
Paralelamente a la ejecucin de este hilo se ejecutar desde l, otro Thread Timeout.java,
Diagrama 16: Timeout.java
//EJECUCION DE TIMEOVER.JAVA\\ estado.setTimeOver(false); try{ sleep(time); //modificacion de estado.timeOver
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 transaccin de ida y vuelta Modbus, y modificar el otro valor de estado timeOver, que tiene bloqueada la ejecucin. Una vez modificado uno de los dos atributos, continuaria la ejecucin.
//CONTINUA LA EJECUCION EN ESTADO.JAVA\\ to.isOutdated(true); if(!tramaOutReady) tramaReceived = new Trama("0x00"); //modifica Timeover.java: timeover ya no es util
Si se ley algo de la red Modbus antes de que acabara Timeout, continuara la ejecucin desprecindose el timeout. En caso contrario se crea una trama falsa.
Memoria. RemModbus
65
3.3.6 Programacin del finding: FindDevices.java
Sigue el proceso tpico:
Comienzo: Modificacin de atributos implicados en estado Desarrollo: Lgica + Modificacin de atributos implicados en estado Finalizacin: Modificacin de atributos implicados en estado
Lgica
Dado que manejamos un campo de direccin o nmero de esclavo de 16 bits (recordemos su representacin lgica en hexadecimal: 0xAA) vamos a tener 216 1 = 255 direcciones posibles, de las que sabemos que 0xC7 y 0x00 no estn disponibles.
Se crear un bucle desde i = 1 hasta i < 256 donde en cada iteracin 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.
Memoria. RemModbus
66
3.3.7 Programacin del polling
Sigue el proceso tpico:
Comienzo: Modificacin de atributos implicados en estado Desarrollo: Lgica + Modificacin de atributos implicados en estado Finalizacin: Modificacin de atributos implicados en estado
Lgica
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 informacin falsa. Esta situacin 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 comprobacin
if(estado.isTramasPollingChanged()){ tramasPolling = estado.getTramasPolling(); it = tramasPolling.iterator(); tramasPollingOut = new ArrayList(); }
Memoria. RemModbus
67
3.3.8 Programacin del CRC
El mtodo de clculo de CRC est localizado en la clase Trama, del paquete pfc_dsm.Modbus. El propio mtodo tiene un sistema para detectar si el CRC se ha incluido previamente en la trama, no aadindolo por tanto. Esto es til sobre todo para la utilizacin como puente del sistema.
Se han tenido muchos problemas con la programacin de esta suma de verificacin. Los diagramas no eran suficientemente claros y no se tena conocimiento del funcionamiento de los operadores de datos. Finalmente se opt por utilizar cadenas binarias representadas sobre Strings. Para facilitar la comprensin del mtodo se muestran los dos campos del CRC que dara 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
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
Ntese que del resultado final se divide en dos cadenas de 8 bits y se cambian de posicin.
Memoria. RemModbus
69
3.4 Programacin 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 utilizacin del sistema: conexin, funciones del servidor, recuperacin de estado del servidor, comunicacin modbus, etc. Muchos de estos mtodos que implementa como String modbusCommunication (String trama) son los mismos que se utilizan en el servidor, ligeramente adaptados. Para la implementacin de puentes por ejemplo se utiliza una versin modificada de ese mismo mtodo modbusCommunication, que consiste en envolver ese mtodo en su homonimo del servidor, pero invertido. De ah el nombre
reverseModbusComunication():
Enva trama
Recibe trama
Figura 19: modbusComunication (server)
En el servidor este mtodo simplente enva una trama a la red serie y recibe su respuesta
Memoria. RemModbus
70
Recibe trama
Enva tramaInet
Recibe tramaInet
Enva trama
Figura 20: reverseModbusCommunication (cliente)
La funcin para el cliente funciona inicialmente de la forma inversa. Escucha en un puerto, y lo que recibe lo reenva utilizando modbusComunication del cliente, la cual invoca al mtodo 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 grfico. Finalmente esta trama se enva al puerto COM desde el que se recibi la trama original.
4 API RemModbus
Se ha desarrollado una API siguiendo la esttica de las APIs de Java. Para mas informacin, se encuentra en la parte de Manuales de Usuario. Consulte el ndice.
Memoria. WebCP2003, RemCP2003 & RemBridge
71
Captulo 3 WEBCP2003, REMCP2003 & REMBRIDGE
1 Introduccin
En este captulo tiene como propsito centrarse en el diseo, fases y programacin de las aplicaciones que hacen uso remoto de la red Modbus mediante RemModbus.
No se prestara demasiada atencin al diseo y programacin de los programas RemModbus2003 y RemBridge, ya que no presentan ningn tipo de complicacin o entramado a ese nivel, y se limitan a simplemente a instanciar la clase RemoteConnection y utilizar los mtodos no utilizados directa o claramente por Web2003.
Por otro lado tenemos Web2003, que s que es un sistema que consta de un completo diseo y una buena programacin. Est basado en el acceso a la red Modbus a travs de RemModbus como las otras, pero con la peculiaridad de que est montado sobre un Web Service y ofrece sus servicios a travs de un simple navegador Web, incluso desde una PDA o un telfono mvil.
72
2 Requerimientos funcionales
[R01] Un usuario debe tener asignado un nivel. Owner (nivel alto) Subscriber (nivel bajo). [R02] Solo podrn acceder al sistema los usuarios registrados en RemModbus. [R03] Todo usuario del sistema sin nivel se le asignara el nivel Subscriber para la sesin. [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 aada 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 vaco. [R12] El sistema debe mostrar cundo esta ocupado el servidor, actualizando los dispositivos conectados, y el tiempo estimado hasta que vuelva a quedar libre. [R13] Todo usuario debe tener opcin de consultar informacin a cerca de los dispositivos conectados. [R14] Todo usuario debe tener opcin de desconectarse de RemModbus. [R15] El sistema reconocer situaciones en las que se pueda estar manejando informacin obsoleta, y ofrecer al usuario la opcin de actualizarla
Administrar: Dar de alta nuevos usuarios, borrar usuarios, modificar usuarios
73
3 Requerimientos no funcionales
[NF01] La aplicacin debe validar la informacin [NF01] La aplicacin debe utilizar Apache Tomcat como servidor. [NF01] La aplicacin debe ser desarrollada en JSEE. [NF01] La aplicacin debe utilizar tecnologa basada en Servlets [NF01] Las pginas mostradas deben ser JSP
4 Modelo de dominio
Diagrama 17: Modelo de dominio WebCP2003
El diagrama superior muestra los conceptos bsicos del dominio del problema as como las relaciones ms importantes entre las entidades principales.
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 funcin de su nivel, a partir de la informacin plasmada en los requerimientos funcionales. Se describe un caso de uso para la ayuda a su interpretacin. Todo usuario de tipo Owner tiene opcin de aadir una medida al polling, pero un usuario de tipo Subscriber no
75
6 Descripcin de los casos de uso
Login Actor principal Actor secundario Condiciones previas Trigger Escenario principal
Usuario -
Submit del usuario

1 2 3
El sistema muestra la pgina de acceso El usuario rellena usuario y contrasea El sistema reenva a la pgina principal
Variaciones
2a. El usuario no rellena todos los huecos 2b. El usuario / contrasea son incorrectos
1 2 3
El sistema muestra pgina de error El usuario confirma Vuelta a 1
Excepciones
2a La conexin con RemModbus no est disponible

Logout Actor principal Actor secundario Condiciones
Usuario -
76
previas Trigger Escenario principal
Seleccin del usuario

1 2
El usuario pulsa Logout El sistema reenva a la pgina de login
Excepciones

Ver dispositivos Modbus Actor principal Actor secundario Condiciones previas Trigger Escenario principal
Usuario -
Operacin de Servlet
1
El sistema muestra la pgina de bienvenida con los usuarios conectados
Variaciones
1a. No hay dispositivos conectados 1b. El servidor se est actualizando

1
El
sistema
muestra
el
(los)
aviso(s) ofrece
correspondiente(s) en la misma pgina y actualizar el estado

2 3
El usuario confirma Vuelta a 1
1a.2a. El usuario no confirma 1b.2a. El usuario no confirma
77
No se actualiza hasta la siguiente accin de servlet.
Excepciones

El sistema muestra pgina de error El usuario confirma Vuelta a pagina de inicio
Ver medidas de un dispositivos Modbus Actor principal Actor secundario Condiciones previas Trigger Escenario principal
Usuario -
Seleccin de usuario
1
El usuario elige un dispositivo de la lista de dispositivos
El sistema muestra la pgina del dispositivo con las medidas
Variaciones Excepciones

2a. La informacin puede estar obsoleta 2b. El servidor se est actualizando
El
sistema
muestra
el
(los)
aviso(s) ofrece
correspondiente(s) en la misma pgina y actualizar el estadoEl usuario confirma
78
Editar medidas de un dispositivos Modbus Actor principal Actor secundario Condiciones previas Trigger Escenario principal
Usuario Estar en la pgina de dispositivo Usuario Owner Seleccin de usuario

1
El usuario elige una medida de la lista de medidas para observar o dejar de observar
El sistema muestra que se ha modificado el polling. Cada vez que se muestre una pgina se debe de ofrecer la opcin de actualizarlo en el servidor o de deshacer los cambios

El
sistema
muestra
el
(los)
aviso(s) ofrece
79
Actualizar polling en el servidor Actor principal Actor secundario Condiciones previas Trigger Escenario principal
Usuario Usuario Owner
Seleccin de usuario
1
El usuario elige una medida de la lista de medidas para observar o dejar de observar
El sistema lo actualiza y retira el mensaje de polling modificado.

1b. La informacin puede estar obsoleta 1c. El servidor se est actualizando
El
sistema
muestra
el
(los)
aviso(s) ofrece
Administrar usuarios Actor principal Actor secundario
Usuario -
80
Condiciones previas Trigger Escenario principal
Usuario Owner
Seleccin de usuario
1
El sistema muestra que el usuario tiene permisos para administrar usuarios
2 3
El usuario selecciona la opcin El sistema muestra los usuarios, contraseas y permisos.
4 5
El usuario realiza alguna actualizacin El sistema ejecuta la decisin del usuario y refresca la pgina.

El
sistema
muestra
el
(los)
aviso(s) ofrece
correspondiente(s) en la misma pgina y actualizar el estadoEl usuario confirma 5a. Fallo de la base de datos

81
Start/Stop de Polling Actor principal Actor secundario Condiciones previas Trigger Escenario principal
Usuario -
Seleccin de usuario
1
El sistema muestra la opcin de arrancar o parar el polling en funcin de como est, siempre que no est vaco.
2 3
El usuario selecciona Start/Stop El sistema ejecuta la operacin y refresca la pgina

2a. La informacin 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 aplicacin antes de continuar con el cambio de estado
2b. El servidor se est actualizando
El
sistema
muestra
el
(los)
aviso(s) ofrece
82
Start de Finding Actor principal Actor secundario Condiciones previas Trigger Escenario principal
Usuario Usuario Owner
Seleccin de usuario
1
El sistema muestra la opcin de arrancar el finding si tiene sospecha de que est obsoleto.
2 3
El usuario selecciona Start El sistema ejecuta la operacin y refresca la pgina

2a. La informacin 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 aplicacin antes de continuar con el cambio de estado
Hay bastantes ms casos de uso pero dado que todos siguen la misma lgica no se aadirn ms a este documento.
83
7 Diagramas de secuencia
A continuacin se mostraran los diagramas de secuencia de los procesos ms importantes y una breve explicacin de los mismos si procede.
7.1 Procesos de login y logout
Diagrama 19: Secuencia de Login
El proceso se fundamenta en la creacin de un nuevo usuario, su validacin en el servidor por medio de RemoteConnection, y su actualizacin con el permiso. La creacin y uso de Display se explicar ms adelante. Se enva el control a WelcomeServlet cuyo diagrama de secuencia se encuentra tambin detallado.
84
Diagrama 20: Secuencia de Logout
Si un usuario desea desconectarse, deber poder hacerlo en cualquier pgina por eso sera interesante incluir un botn de logout en todas las cabeceras de pgina. El proceso de desconexin o logout es muy simple, ya que no requiere nada ms que solicitar la accin a RemoteConnection. A continuacin se destruyen user y RemoteConnection para permitir nuevas conexiones y no tener datos de sesin.
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 sesin se actualizar en trminos de dispositivos conectados y lista de tramas de polling. El sistema Web ofrece un sistema que permite reconocer situaciones potenciales de informacin obsoleta. Unos ejemplos de situacin potencial de informacin obsoleta, seran
86
que las tramas de polling de medidas no puedan ser interpretadas que una consulta de peticin de nmero de serie devuelva error que las tramas de polling se hayan modificado en la aplicacin Web y no estn actualizadas etc. El sistema se ha diseado para que la pgina 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 situacin, se realicen en dicha pgina. A la hora de programar esto lo hemos solucionado con variables verdadero/falso que se estructuran dentro de la clase Display, para mantener ms 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> <% } %>
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 estn tomando o se pueden tomar del dispositivo seleccionado en la pantalla anterior. En resumen, la JSP encargada de mostrar esa informacin acceder a los datos necesarios, que ViewDeviceServlet ha preparado para ella. Ntese que puede ser tambin entendido el diagrama como el diagrama de secuencia de ViewDeviceServlet, desde la instruccin 1.1.1.
88
Interpretando los datos
[Para ms informacin, consultar Anexo 1: CP200X Communication Protocol] El dispositivo CP2003, aunque es extensible a muchos dispositivos Modbus, ofrece la informacin en cinco formatos diferentes.
ASCII: Como caracteres, enviados en el orden especfico. Utilizado para operaciones como lectura del nmero de serie, etc.
BYTE: Ocho bits. Utilizado para parmetros 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 interpretacin y programacin de esto ha sido complicada. Se explicar como se ha de interpretar la informacin de este tipo. Como hemos visto se deben leer cuatro Bytes, que tendrn la siguiente informacin: BYTE1: SIGNO + EXPONENTE BYTE2: MANTISA HIGH BYTE3: MANTISA MIDDLE BYTE4: MANTISA LOW
Most Significative Bit: Bit ms significativo Less Significative Bit: Bit menos significativo
89
Hay que tener en cuenta que la posicin real de esos Bytes no se ajusta a esa numeracin sino que hay que modificar la posicin de las parejas de WORDS. Asi por ejemplo el hipottico PDU recibido de una trama 0x0A-0x00-0x43-0x5E, sera de acuerdo a la numeracin 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:

Ecuacin 2: Clculo de dato IEEE
23 Value = 1SIGNO * 2 EXP 127 * 1 + 2 i * M i i =1
Para hallar el valor de los parmetros:
Byte1
Byte2
SG E7
E6 E5 E4
E3 E2 E1
E0 M1 M2 M3 M4 M5 M6 M7 MANTISA ->
Byte4
EXPONENTE
Byte3
M8 M9 M10M11M12M13M14 M15
M16M17M18M19M20 M21M22M23
<- MANTISA
90
7.4 Editar medidas
Diagrama 23: Secuencia de Editar Medidas del Polling
Se debe tener en cuenta que despus de la accin detallada el sistema Web no estar en concordancia con el sistema RemModbus. WebCP2003 mostrar un aviso con dos opciones, deshacer los cambios (recargara el polling del servidor) o actualizar el polling en el servidor (modificar el polling del servidor). Para estas opciones, como para las dems que se presentan se utilizarn los mtodos de RemoteConnection. Consultar la API desarrollada y adjunta para ms informacin.
91
7.5 Administrar usuarios
El diagrama se divide en dos partes, la de acceso a la pgina de edicin de usuarios y la de la administracin en si.
Diagrama 24: Secuencia de Administrar Usuarios
Solo si un usuario es Owner se le mostrar la opcin de administrar a los usuarios.
92
7.6 Arrancar procesos en el servidor
Diagrama 25: Secuencia de Arrancar Finding
En el diagrama se muestra como ejemplo como funciona la lgica 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 actualizacin y la secuencia se ve ms clara. Si se presta atencin al punto 3, se solicita el estado del finding antes de arrancarlo. Esto se hace por si el proceso ha sido arrancado mientras la pgina no era refrescada. Hay que tener en cuenta tambin 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.
93
8 RemCP2003
Ilustracin 1: RemCP2003
Esta aplicacin modular tendr como objetivos probar la conexin a RemModbus desde una aplicacin Java probar el uso de una comunicacin Modbus (request response)
94
9 RemBridge
Esta aplicacin 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, refirase al Captulo 2 RemModbus, apartado 3, Programacin y pruebas, para la correcta y siga los pasos de instalacin de libreras de RemModbus. Adems se precisar crear dos puertos COM virtuales y establecer una comunicacin entre ellos. Existen programas ya desarrollados con esa finalidad como VSPD XP4.
Modbus app sobre RemBridge INET virtual COM2
RemModbus Servidor
COM3 COM1 ESCLAVO TCP/IP TCP/IP
Figura 21: Lgica RemBridge
COM1 y COM2 son puertos virtuales con una conexin virtual entre ellos de manera que lo que enva uno, es recibido por el otro. RemBridge escucha en COM2 y una aplicacin Modbus local cualquiera se conecta a COM1 como si el dispositivo estuviera conectado a ese puerto y enva una trama. Al recibir informacin RemBridge la reenva por TCP usando RemModbus.RemoteConnection. La trama se procesa como un DAT_ABS (ver diseo de protocolo RemModbus) y se enva la respuesta. RemBridge la recibe y la transmite a COM2, por lo que la aplicacin Modbus recibir esa informacin de COM1.
Memoria. Resultados/Experimentos
95
Captulo 4 RESULTADOS/EXPERIMENTOS
1 RemModbus
Es una aplicacin que de forma remota y local,
Permite administrar una red Modbus. Proporciona la comunicacin bsica Modbus: intercambio de tramas. Permite mediante una instanciacin muy sencilla, el acceso de cualquier aplicacin Modbus a la red, de forma remota. Permite acceso mltiple a la aplicacin. Permite varios dispositivos Modbus conectados Ofrece facilidades de uso de Modbus a programadores industriales generalmente Ofrece una documentacin en forma de API que facilita an ms la programacin y el diseo de aplicaciones Modbus. Permite control de acceso a la red e implantacin 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 bsqueda automtica de dispositivos Modbus conectados a la red, a la que hemos dado el nombre de finding Ofrece control y recuperacin de errores sobre una arquitectura que originalmente no la tiene (Modbus) Permite un enlace transparente con la red Modbus y con el protocolo RemModbus.
96
2 WebCP2003
Es un servidor Web que esta diseado para obtener de forma remota informacin de uno o varios dispositivos CP2003 y adems, 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 ejecucin de consultas definidas sobre un CP2003. Implementar la comunicacin bsica request-response.
4 RemBridge
Una instanciacin de la utilidad de RemModbus para la creacin de puertos virtuales Permite acceder a la red administrada por RemModbus y por tanto a sus dispositivos de forma totalmente transparente. Cualquier aplicacin interactuar con la red de forma remota sin saberlo.
97
5 Experimentos
Durante el estudio del diseo de la arquitectura fsica de la red Modbus, se repar en el convertidor hardware de seal RS232 a RS485. Surgi la idea de realizar la conversin entre los protocolos por medio de software, por lo que se procedi al estudio preliminar de la seal. 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 mnimas, ya que lo que variaba de una a otra era el significado de 1 y 0 (tensin en uno, y no tensin en el otro). Aparentemente la intensidad tambin variaba. Sin embargo implementar este mtodo hubiera supuesto demasiado estudio de la situacin y arquitectura de los medios de transmisin, ya que no se saba si fsicamente se poda hacer.
Tambin se ha descartado la idea de la actualizacin automtica 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 funcin estuvo implantada durante mucho tiempo en el sistema, pero finalmente se retir de l por dos razones importantes: La primera, que dada la lgica 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.
Memoria. Conclusiones
98
Captulo 5 CONCLUSIONES
Hay que tener en cuenta que se careca de base alguna acerca de cmo funcionaban los entornos o las comunicaciones industriales antes del desarrollo de la aplicacin. Normalmente no son mbitos de los que un ingeniero informtico 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 familiarizacin con los dispositivos y de estudio de arquitecturas y de alternativas de desarrollo. Se ha gastado mucho tiempo consultando distintas pginas 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 haba utilizado un osciloscopio, un plc o un pupitre de mando, de los que lo ms que tena 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 ms sencillos, e ir atajndolos poco a poco. Me he divertido haciendo el proyecto y tambin lo he pasado mal. Me he visto superado por la funcionalidad que deba tener el proyecto, y he sabido cmo solucionarlo.
Se ha mejorado la capacidad de diseo. Adems se ha comprobado que el tiempo que se pierde diseando o elaborando diagramas, se gana a la hora de programar. Un muy buen diseo puede convertirse en una especie de guin para el programador, donde este solo tenga la necesidad de disear. El buen diseo en este proyecto ha permitido la creacin de utilidades que facilitan la programacin. El ejemplo ms claro es RemModbus pero esa filosofa la encontramos tambin a lo largo de todo el proyecto, por ejemplo en la definicin de un protocolo de comunicacin por Internet.
Memoria. Conclusiones
99
Se han utilizado una gran cantidad de tecnologas lo que ha mejorado mi programacin y ms concretamente mi manejo de Java, HTML, SQL, CSS, Servlets, etc. Se han aprendido muchas tcnicas de programacin: 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 diseo y de programacin. Personalmente espero que nuestro proyecto pueda se realmente til, ya sea en su programacin, su diseo, o en su concepto, y pueda ser utilizado por otros programadores o usuarios.
Es importante destacar la aportacin realizada, de desarrollar una herramienta y su API para desarrollar el objetivo inicial, que consista simplemente en desarrollar una aplicacin que se conectara remotamente un dispositivo Modbus, el CP2003. Esto nos hizo cambiar el alcance de la aplicacin, limitando un poco la funcionalidad que tendra inicialmente la aplicacin inicial, y desarrollando dos sistemas ms modulares que realicen las operaciones sobre el dispositivo, pero aadiendo el valor aadido de RemBridge (Ver Captulo 3, apartado RemBridge). Con esta aportacin ampliamos el rango de utilizacin a otras aplicaciones Modbus que funcionen sobre otros dispositivos, y facilitamos el desarrollo de otras aplicaciones aumentando considerablemente el grado de abstraccin sobre detalles tcnicos.
Memoria. Futuros desarrollos
100
Captulo 6 FUTUROS DESARROLLOS
Para poder aseverar que el proyecto se ha terminado y puede ser distribuido quedan cosas por hacer. Cosas que an 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 ms opciones en el servidor. S que esto puede suceder, puesto que me ha sucedido a mi mismo, a pesar del buen diseo del sistema, del que se hace gala con anterioridad. Es importante que otros diseadores y programadores creen aplicaciones reales para ver que necesidades, no pueden ser satisfechas por el sistema. Afortunadamente El diseo de la aplicacin es tan flexible y modular que permite aadir fcilmente nuevas funcionalidades.
Por otra parte los programas de utilizacin de CP2003 estn 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 situacin, 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 aplicacin que cree un puente y dos puertos COM virtuales, y los conecte entre ellos. Con ms tiempo se podra haber incluido esta faceta en el alcance o el mbito del proyecto. Sera muy interesante desarrollar este punto, aunque el desarrollo de la API para programadores perdera un poco de sentido, o mejor dicho, de utilidad.
101
Adems, hay elementos que se ha visto que pueden hacer la aplicacin ms flexible o ms 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 pblicas o compartidas no se podrn realizar conexiones a ese puerto. Adicionalmente hace que la aplicacin sea dependiente de un elemento absolutamente externo y esttico. Se recomienda implementar un mtodo que permita de forma automatizada: 1. Cambiar la localizacin 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 seal RS232 a RS485 por software. Estudiar la posibilidad real de realizar esta conversin. Ver captulo de Resultados/Experimentos para ms informacin. Permitir comunicacin Modbus ASCII [Ver Programacin RemModbus]. Llevara un tiempo cambiar la lgica pero no sera complejo el diseo. Se ofrecen ideas de referencia para su implantacin. 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 cmo est funcionando el sistema.
3. Creacin alternativa de Trama.java

Establecer utilidades que creen el formato tpico de las tramas cuando se comunican entre procesos o aplicaciones, a partir de ArrayList(), Vector(), etc. Y la utilidad inversa. Se podra haber implementado ya pero no se tena la necesidad ya que cuando surgi la idea ya no era necesario.
102
Estudiar la posibilidad o la utilidad de implementar en el servidor de RemModbus o en una aplicacin que se conecte, el envo de e-mails ante medidas tomadas que se hayan preestablecido como peligrosas o dignas de observacin. 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 grficas de evolucin y permitir un estudio ms exhaustivo de la evolucin de los resultados del polling. Estudiar si es competencia de RemModbus o de aplicaciones que hagan uso de el.
Memoria. Estudio Econmico
103
Captulo 7 ESTUDIO ECONMICO
1 Planificacin previa
Ilustracin 2: Planificacin inicial
Memoria. Estudio Econmico
104
2 Uso real aproximado del tiempo invertido en el proyecto
Investigacin y aprendizaje: 60 horas Identificacin de necesidades: 15 horas Diseo: 120 horas Programacin: 100 horas Pruebas: 20 horas
Teniendo en cuenta que algunas actividades se solapan, el trabajo habr llevado unas 300 horas. Si a esto le aadimos la documentacin, nos moveramos en torno a las 350 horas.
3 Valoracin econmica
Se quiere estimar el coste real del proyecto, incluyendo horas de trabajo, software y hardware y material empleado para el aprendizaje.
Equipo (a 3 aos): 200 Software (VSPD XP4): 90 Horas de trabajo: 7000 Libros: 100
COSTE TOTAL DEL PROYECTO: 7400
Memoria. Bibliografa
105
BIBLIOGRAFA
[1] Eckel, Bruce Thinking in Java (3rd Edition Revision 4) (2002) Prentice Hall. [2] Barranco de Areva, J. Metodologa del anlisis 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. Tecnologa 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] Rodrguez Mondjar, J.A.; Fundamentos de Comunicaciones Industriales. Universidad Pontificia Comillas, Practicas de Laboratorio. [8] Rodrguez Mondjar, J.A.; Comunicaciones Industriales Avanzadas. Universidad Pontificia Comillas, Practicas de Laboratorio. [9] Jimnez Buenda, M.; Comunicaciones Industriales Universidad Politcnica de Cartagena, Departamento de Tecnologa Electrnica. [10] Ruiz Olaya, L.F.; Implementacin de una red Modbus/TCP (2002) Escuela de Ingeniera Elctrica y Electrnica de Santiago de Cali, Tesis [11] SACI, CP2003 Communication Protocol (2001) SACI, Manuales [12] [13] Guas, Manuales y Especificaciones: http://www.modbus.org/specs.php http://www.simplymodbus.ca/FAQ.htm
Memoria. Bibliografa
106
[14] [15] [16] [17] [18] [19] [20]
http://jamod.sourceforge.net/kbase/protocol.html http://www.rtaautomation.com/modbustcp/index.html http://www.intellicom.se/ModbusTCP_overview.shtml http://java.sun.com/products/javacomm/reference/api/index.html http://java.sun.com/j2se/1.4.2/docs/api/ http://es.wikipedia.org/wiki/ y http://en.wikipedia.org/wiki/ http://java.sun.com/products/javacomm/reference/faqs/index.html
Anexo I Manuales de usuario. Bibliografa
107
ANEXO I MANUALES DE
USUARIO
Anexo I Manuales de usuario. API de RemModbus
108
Captulo 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 Martnez
Field Summary
static int
MAIN_PORT
Port number where the server receive incoming connections
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()
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:
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
Anexo I Manuales de usuario. Manual de RemModbus
112
Captulo 2 MANUAL DE REMMODBUS
Este captulo contendr una breve descripcin del servidor RemModbus y su manejo.
Ilustracin 3: RemModbus Servidor
Para empezar a administrar la red Serie y las conexiones entrantes debemos pulsar sobre los botones de conexin 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 continuacin. Sobre ella tendremos que elegir bajo qu parmetros vamos a controlar la red Modbus. (Velocidad de transmisin, bits de parada, puerto COM que proporciona la conexin a la red, etc.)
113
Ilustracin 4: Configuracin de la conexin Modbus
Mediante el men desplegable Men de la parte superior de la aplicacin tendremos acceso a los procesos de finding y polling. El men Administracin debe ser manejado con cuidado ya que permite modificar parmetros internos del programa.
Ilustracin 5: Men Administracin
114
La primera opcin nos permitir introducir manualmente los dispositivos que estn 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 nmero de esclavo de los dispositivos de antemano.
Ilustracin 6: Introducir direcciones manualmente
Para modificar el resto de las opciones del men se abrirn ventanas similares a la anterior. La segunda opcin 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 tambin desde el 0x10 al 0xFF. La ltima de las opciones de este men sirve para decidir cunto deseamos esperar antes de suponer que la red no contestar a la trama.
115
Ilustracin 7: RemModbus funcionando
RemModbus se estructura en 5 ventanas principales, cada una con una finalidad informativa. La primera muestra la actividad local e interaccin 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.
Anexo I Manuales de usuario. Manual de WebCP2003
116
Captulo 3 MANUAL DE WEBCP2003
1 Entrar en la aplicacin
Ilustracin 8: Entrando en WebCP2003
Esta es la primera pgina de la aplicacin. Para evitar complicaciones se ha establecido un usuario ya registrado y su contrasea en la pantalla de inicio. Una vez validados pasaremos a la pgina principal de la aplicacin, 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
117
2 Sistema inteligente de interaccin
El manejo de la aplicacin 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 ms lgicas para cada situacin concreta. Esto se ha llevado a cabo mostrando mensajes emergentes en la pantalla principal antes mencionada, que informan de la situacin actual y las posibilidades de interaccin en ese marco. El manejo es muy intuitivo y fcil de comprender. A continuacin se muestra un ejemplo del funcionamiento con dichos mensajes.
Ilustracin 9: Sistema inteligente de interaccin
Vemos en la ilustracin como el sistema ha detectado una situacin potencial de informacin obsoleta, y vemos tambin 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.
118
3 Interaccin simple
Hemos visto que el sistema se adapta automticamente a la situacin 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 accin o un proceso, independientemente del estado de la red, bien porque tenga informacin 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 botn Herramientas, que abrir un pequeo men, que permite interactuar como se ha mencionado.
Ilustracin 10: Men Herramientas
Al accionar este men, se desactivarn automticamente los mensajes del sistema inteligente, relacionados con l. La utilizacin de este men est restringida a los usuarios de ms alto nivel, por razones de seguridad.
119
4 Administracin del polling y obtencin 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 algn cambio en el polling y ofrecer la posibilidad de guardar los cambios o por contrario, volver al estado inicial del servidor.
Ilustracin 11: Modificando el polling
En el ejemplo de arriba estamos aadiendo 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 ms de un dispositivo.
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 pgina principal con el siguiente aviso en forma de mensaje.
Ilustracin 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 ilustracin.
Ilustracin 13: Start/stop polling
121
5 Administracin de usuarios
Al sistema de administracin de usuarios slo podrn acceder los usuarios de nivel ms alto. Para ello se dispondr de un acceso por medio de mensaje tpico de la aplicacin, 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 edicin en la pgina de administracin de usuarios, con el botn Seleccin de niveles de usuario
Ilustracin 14: Cambiando nivel de usuario
122
Esta accin nos devolver a la misma pgina 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.
Ilustracin 15: Modificando usuarios
5.2 Borrar usuario
El mtodo 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.
123
5.3 Aadir usuario
Los usuarios se aaden por medio del men desplegable Aadir Usuarios de la pgina de administracin de usuarios, que se mantendr desplegado hasta que terminemos de aadir usuarios y volvamos a plegarlo.
Ilustracin 16: Aadiendo usuarios
Se introducen los parmetros requeridos y se aade pulsando el botn.
Ilustracin 17: Usuario aadido
Anexo I Manuales de usuario. Manual de RemCP2003
124
Captulo 4 MANUAL DE REMCP2003
Ilustracin 18: Conexin a RemModbus
Lo primero que se muestra en la aplicacin es la ventana de conexin a RemModbus. Introducimos usuario, contrasea y la direccin en la que reside la aplicacin, y pulsamos sobre el botn de conexin. La aplicacin ofrece dos modos de actuacin segn en que pestaa nos encontremos. La pestaa inicial nos permite conocer la situacin actual de un determinado valor.
Ilustracin 19: RemCP2003. Toma de medidas
Anexo I Manuales de usuario. Manual de RemCP2003
125
En la ilustracin de la pgina anterior hemos tomado la medida de voltaje VFR sobre el dispositivo con direccin 0x03 y hemos obtenido un resultado de 222 V.
Ilustracin 20: RemCP2003. Avanzado
La segunda pestaa nos permite actuar como administrador de cualquier red Modbus introduciendo una trama arbitraria en la red. Para crear la trama se aade Byte a Byte en hexadecimal. No se ofrece clculo de CRC pero si RemModbus detecta que no tiene CRC, lo aadir l mismo. Vemos como se ha enviado la trama aleatoria 0x330x33-0x33-0x33-0x33-0x33- la cual lgicamente no ha obtenido respuesta como se refleja abajo.
Recordemos que RemCP2003 slo funciona con la modalidad DAT_ABS de RemModbus por lo que si el servidor est ocupado, la aplicacin quedar esperando a que termine el servidor, para recibir una respuesta a la peticin que se haga.
Anexo I Manuales de usuario. Manual de RemBridge
126
Captulo 5 MANUAL DE REMBRIDGE
El funcionamiento es muy sencillo ya que tan solo consiste en conectarse a RemModbus con una ventana de conexin [Ilustracin 18: Conexin a
RemModbus] y posteriormente en conectarse a un puerto COM del ordenador en el

que reside la aplicacin [Ilustracin 4: Configuracin de la conexin Modbus], a travs del cual capturaremos el trfico y lo enviaremos al servidor, que tratar las tramas como cualquier otro programa RemModbus.
Ilustracin 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 tpicas Modbus.
Anexo 2 CP200X Communication Protocol. Manual de RemBridge
127
ANEXO 2 CP200X COMMUNICATION PROTOCOL

Modbus Java

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modbus Java

Uploaded by

Copyright:

Available Formats

.

Los resultados finales obtenidos son:

The final results are the following:

Memoria ..................................................................................................................... 1 Captulo 1

Estado del arte.......................................................................................................... 3 Motivacin del proyecto ........................................................................................ 7

Motivacin del proyecto ...................................................................................... 11

Programacin y pruebas ...................................................................................... 48

WebCP2003, RemCP2003 & RemBridge...................................... 71

Captulo 5 Captulo 6 Captulo 7

Conclusiones.................................................................................... 98 Futuros desarrollos....................................................................... 100 Estudio Econmico ....................................................................... 103

pfc_dsm.RemModbus Class SerialPort .................................................................. 108

Manual de RemModbus ............................................................... 112 Manual de WebCP2003 ................................................................ 116

Manual de RemCP2003 ................................................................ 124 Manual de RemBridge.................................................................. 126

Anexo 2 CP200X Communication Protocol...................................................... 127

1 Estado del arte

NIVELES OSI 7 6 5 4 3 2 1 Aplicacin Presentacin Sesin Transporte Red Enlace Fsico SI NO NO NO NO SI SI

Tramas Modbus RS485 o RS232

Figura 1: Niveles OSI y aplicaciones Modbus

Figura 2: Comunicacin Modbus

Figura 3: Trama Modbus RTU o

ID (1Byte) es el nmero de esclavo, que hace las veces de direccin.

CMD (1Byte) es el tipo de orden enviado al esclavo. Hay dos tipos

Figura 4: Comandos Modbus

INFO (nBytes) definido anteriormente como PDU, contiene la

CRC (2Bytes) Mecanismo de control de errores de transmisin (cyclic

2 Motivacin del proyecto

Figura 5: Trama Modbus RTU encapsulada sobre Modbus/TCP

Modbus Master 1 (Cliente)

INTERNET INTRANET Modbus TCP

Esclavo 1 RS232 Modbus RTU (Maestro)

TCP/IP Modbus Master 2 (Cliente)

Figura 6: Arquitectura Modbus/TCP. Maestros en el lado TCP

2.2 Uso del CP2003

Red Elctrica CP2003

Figura 7: Conexin bsica del CP200X

3 Motivacin del proyecto

3.2 Desarrollo de aplicaciones Modbus remotas

Servidor TCP/IP Maestro Modbus

RS485 Esclavo #2 Modbus

Figura 8: Ventajas wireless aplicadas al mundo TCP - Modbus

3.3 Controlador remoto del CP2003

1. Necesidad de ofrecer un servicio: El origen de este proyecto surge de la

2. Necesidad de probar la herramienta de desarrollo: Desde un punto de

4.1.1 Objetivos Generales

Figura 9: Cooperacin entre productos finales

4.1.2 Objetivos de RemModbus

4.1.3 Objetivos de RemCP2003

4.2 Alcance de la aplicacin

4.3 Tipologa de los usuarios

Programadores y desarrolladores industriales o relacionados con el protocolo Modbus.

Usuarios de dispositivos o redes Modbus. Usuarios de CP2003.

Para la ejecucin del Web Service de WebCP2003, se necesitar Apache Tomcat.

6 Recursos, herramientas y tecnologas empleadas

Para el desarrollo de en Java se ha utilizado

o Notepad++ 4.5 para ediciones puntuales de cdigo.

o MySQL Java Connector 5.1.6 para permitir a la aplicacin Java

o Microsoft Office XP o Adobe Photoshop CS2 para la edicin de grficos

Se han utilizado varias tecnologas de comunicaciones

o CP2003 o PLCs y pupitre de mando para proporcionar mas funcionalidad al

o Windmill comDebug y Hyperterminal para la captura e interpretacin

o Convertidor USB Serial o Convertidor RS232 RS485

7.2 RemCP2003 y WebCP2003

7.3 Arquitectura extendida de la aplicacin.

WebCP2003 RemCP2003 Usando Cliente 3 RemModbus