modbus java

. Resumen

i

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

v

NDICE

Memoria ..................................................................................................................... 1 Captulo 11 2

Introduccin....................................................................................... 2

Estado del arte.......................................................................................................... 3 Motivacin del proyecto ........................................................................................ 72.1 Modbus sobre TCP ..................................................................................................................7 2.2 Uso del CP2003.......................................................................................................................9

3

Motivacin del proyecto ...................................................................................... 113.1 Desarrollo de un entorno para el desarrollo de aplicaciones remotas Modbus ......................11 3.2 Desarrollo de aplicaciones Modbus remotas..........................................................................13 3.3 Controlador remoto del CP2003............................................................................................15

4

Identificacin de Necesidades............................................................................ 164.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.................................................................................... 257.1 RemModbus y RemBridge ....................................................................................................25 7.2 RemCP2003 y WebCP2003 ..................................................................................................25 7.3 Arquitectura extendida de la aplicacin. ...............................................................................26

Captulo 21

RemModbus ..................................................................................... 27

Introduccin ........................................................................................................... 27


. ndice

vi

2

Diseo ..................................................................................................................... 282.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

3

Programacin y pruebas ...................................................................................... 483.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

4

API RemModbus................................................................................................... 70

Captulo 31 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....................................................................................... 837.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 41 2 3 4 5

Resultados/Experimentos .............................................................. 95

RemModbus........................................................................................................... 95 WebCP2003............................................................................................................. 96 RemCP2003............................................................................................................. 96 RemBridge.............................................................................................................. 96 Experimentos.......................................................................................................... 97

Captulo 5 Captulo 6 Captulo 71 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 .................................................................. 108Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementacin Web y Java del sistema para CP2003.

. ndice

viii

Captulo 2 Captulo 31 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..................................................................................... 1215.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

1

MEMORIA


Memoria. Introduccin

2

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.



3

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,

o

Nivel de aplicacin (aplication layer), donde trabajaran los programas que utilizan los dispositivos e interpretan los datos de dichos instrumentos. (Ej: Windmill, Hyperterminal, etc.).

o

Nivel de protocolo (data-link layer), donde se localizara el intercambio de tramas bsicas del protocolo Modbus.



4

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



5

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

A

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



6

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

o

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.

o

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

redundancy check)



7

2 Motivacin del proyecto2.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.



8

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.



9

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.Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementacin Web y Java del sistema para CP2003.


11

3 Motivacin del proyecto3.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.

1

http://www.lantronix.com/ http://www.intellicom.se/

2



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.

o

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.

o

La gestin de sistemas distribuidos se hace ms sencilla usando las tecnologas de Internet disponibles, por lo tanto conseguiremos mejorar este aspecto.

o

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.

o

Por otra parte podremos aprovechar infraestructuras serie y TCP ya creadas sin necesidad de modificarlas, y continuar ofreciendo conexiones multipunto.

o

Mediante un Standard de comunicacin universal como es TCP/IP y un protocolo pblico Modbus, obtenemos una red realmente abierta, para un intercambio y proceso de datos.



14

o

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 lanecesidad 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 devista 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 Necesidades4.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 desarrolloMtodo 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 divididoFase 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 deJava.Swing.

o Librera Java javax.comm para las comunicaciones serie. o NetBeans Java Runtime Environment (JRE) como entorno deejecucin.

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 detablas e informacin de mi BBDD

o MySQL Java Connector 5.1.6 para permitir a la aplicacin Javaconectarse 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 2002Para 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 alCP2003

o Windmill comDebug y Hyperterminal para la captura e interpretacinde tramas Modbus. Se han utilizado dos convertidores hardware,

o Convertidor USB Serial o Convertidor RS232 RS485Se 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 pginasJSP.

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 arquitectura7.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 IntroduccinEn 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 proyectoDesarrollo en Java de un sistema de acceso remoto a Modbus. Implementacin Web y Java del sistema para CP2003.

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 porqueeste 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 unmtodo 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 quepermita 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 determinadatrama.

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 encondiciones 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 d2se 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 hatransmitido 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.javaNos 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

3

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.javaSe encargara de recibir las conexiones entrantes, decidir si son o no aceptadas y arrancar un servidor personalizado para cada conexin aceptada.

Diagrama 13 Server.ja

modbus java

Documents