Modbus Java

ii

. Resumen

Los resultados finales obtenidos son:

RemModbus

será una aplicación que de forma remota y local, administra una red

Modbus cualquiera. Además facilita el desarrollo de nuevas aplicaciones.

WebCP2003

será todo un sistema de control definido sobre un servidor Web, para

demostrar la potencia de RemModbus, que esta diseñado para obtener de forma remota información de uno o varios dispositivos CP2003

RemCP2003

será un programa Java para la ejecución de consultas definidas sobre

un CP2003. Las tramas se interpretarán.

RemBridge permitirá

la creación de una comunicación entre una aplicación Modbus

cualquiera y un dispositivo Modbus, a través de Internet, usado la tecnología RemModbus desarrollada anteriormente. En la parte del cliente, se ejecutará RemBridge, el cual, se comunicará con un puerto COM virtual. Una aplicación Modbus local cualquiera, se conecta a otro puerto virtual COM como si el dispositivo estuviera conectado a ese puerto. De esta forma RemBribge hace las veces de dispositivo Modbus, y realiza las conexiones pertinentes con RemModbus en el servidor, que llevará a cabo la comunicación real.

Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.

ii

. Resumen

Los resultados finales obtenidos son:

RemModbus

será una aplicación que de forma remota y local, administra una red

Modbus cualquiera. Además facilita el desarrollo de nuevas aplicaciones.

WebCP2003

será todo un sistema de control definido sobre un servidor Web, para

demostrar la potencia de RemModbus, que esta diseñado para obtener de forma remota información de uno o varios dispositivos CP2003

RemCP2003

será un programa Java para la ejecución de consultas definidas sobre

un CP2003. Las tramas se interpretarán.

RemBridge permitirá

la creación de una comunicación entre una aplicación Modbus

cualquiera y un dispositivo Modbus, a través de Internet, usado la tecnología RemModbus desarrollada anteriormente. En la parte del cliente, se ejecutará RemBridge, el cual, se comunicará con un puerto COM virtual. Una aplicación Modbus local cualquiera, se conecta a otro puerto virtual COM como si el dispositivo estuviera conectado a ese puerto. De esta forma RemBribge hace las veces de dispositivo Modbus, y realiza las conexiones pertinentes con RemModbus en el servidor, que llevará a cabo la comunicación real.


iii

. Abstract

Capítulo 2 ABSTRACT The Project named Java Development of a system of remote access to Modbus. Implementation Web and Java of the system for CP2003,

has the last and final goal

of developing an application able to read and interpret measure information of the CP2003 device via the Internet. This device has the overall functionality of taking information from a power grid, as drawing intensity, voltage, etc.. That may allow a study of the situation, for example, for consumption. This device works through the serial Modbus protocol, widely used in industrial environments to control their devices.

To develop this ultimate goal, it was decided to structure the project into two big categories or sub-projects. The first would correspond to the application that knows how to communicate with the device (via Modbus), obtains the information required of him and knows how to interpret it, in other words a sort of controller. The second will be to develop a method that allows us to abstract from the details of Internet communication. That decision has resulted in the design and scheduling of a clientserver application. The server, which resides in the local system connected to the network Modbus, will manage and retrieve details of the Modbus network, and will manage incoming connections TCP / IP. On the client side it must be necessary to implement a class that offers access functions of the application server on the network Modbus. This tool will not implement any special handling of CP2003 in particular, in order to offer their profits to develop other applications Modbus.


iv

. Abstract

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.


v

. Índice

ÍNDICE Memoria ..................................................................................................................... 1 Capítulo 1

Introducción....................................................................................... 2

1

Estado del arte.......................................................................................................... 3

2

Motivación del proyecto ........................................................................................ 7 2.1 Modbus sobre TCP ..................................................................................................................7 2.2 Uso del CP2003 .......................................................................................................................9

3

Motivación del proyecto ...................................................................................... 11 3.1 Desarrollo de un entorno para el desarrollo de aplicaciones remotas Modbus ......................11 3.2 Desarrollo de aplicaciones Modbus remotas ..........................................................................13 3.3 Controlador remoto del CP2003 ............................................................................................15

4

Identificación de Necesidades............................................................................ 16 4.1 Objetivos ...............................................................................................................................16 4.2 Alcance de la aplicación .........................................................................................................19 4.3 Tipología de los usuarios .......................................................................................................20 4.4 Restricciones..........................................................................................................................21

5

Metodología de desarrollo .................................................................................. 22

6

Recursos, herramientas y tecnologías empleadas ........................................... 23

7

Estudio de la arquitectura.................................................................................... 25 7.1 RemModbus y RemBridge ....................................................................................................25 7.2 RemCP2003 y WebCP2003 ..................................................................................................25 7.3 Arquitectura extendida de la aplicación. ...............................................................................26

Capítulo 2 1

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

Introducción........................................................................................................... 27


vi

. Índice

2

Diseño ..................................................................................................................... 28 2.1 Diseño de la Base de Datos ....................................................................................................29 2.2 Diseño del protocolo RemModbus .........................................................................................30

2.2.1 Proceso de conexión y establecimiento de usuario: .............................................................32 2.2.2 Otras transacciones cliente – servidor. Lógica de confirmaciones. .....................................33 2.2.3 Lista de transacciones .........................................................................................................34 2.3 Diseño de RemModbus Servidor ...........................................................................................36

2.3.1 Lógica del enlace físico con los puertos del protocolo Serie. ................................................36 2.3.2 Lógica de conexión de equipos remotos ...............................................................................37 2.3.3 Diseño de control de estado de la red. .................................................................................37 2.3.4 Lógica de colas. ...................................................................................................................40 2.3.5 Lógica de la comunicación Modbus. ...................................................................................42 2.3.6 Diseño de control de obtención de respuestas. ....................................................................43 2.3.7 Lógica del descubrimiento de dispositivos conectados a la red (Finding). ..........................44 2.3.8 Lógica del polling. ..............................................................................................................45 2.3.9 Lógica de transmisión de tramas. CRC. .............................................................................46 2.4 Diseño de RemModbus Cliente .............................................................................................47

3

Programación y pruebas ...................................................................................... 48 3.1 Programación del acceso a la BBDD .....................................................................................51 3.2 Programación del protocolo RemModbus ..............................................................................52 3.3 Programación de RemModbus Servidor ................................................................................55 3.3.1 Programación de gestión conexión con protocolo serie: Enlace.java ..................................56 3.3.2 Programación de gestión de conexiones remotas ................................................................56 3.3.3 Programación de gestión de estado: Estado.java ................................................................58 3.3.4 Programación de colas ........................................................................................................60 3.3.5 Programación de comunicación Modbus y control de obtención de respuestas. ................62 3.3.8 Programación del CRC .......................................................................................................67 3.4 Programación de RemModbus Cliente ..................................................................................69

4

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

Capítulo 3

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

1

Introducción........................................................................................................... 71

2

Requerimientos funcionales............................................................................... 72

3

Requerimientos no funcionales ......................................................................... 73


vii

. Índice

4

Modelo de dominio .............................................................................................. 73

5

Diagrama de casos de uso.................................................................................... 74

6

Descripción de los casos de uso.......................................................................... 75

7

Diagramas de secuencia....................................................................................... 83 7.1 Procesos de login y logout .....................................................................................................83 7.2 WelcomeServlet .....................................................................................................................85 7.3 Ver medidas de un dispositivo ...............................................................................................87 7.4 Editar medidas .......................................................................................................................90 7.5 Administrar usuarios ............................................................................................................91

7.6 Arrancar procesos en el servidor ...........................................................................................92

8

RemCP2003............................................................................................................. 93

9

RemBridge.............................................................................................................. 94

Capítulo 4

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

1

RemModbus........................................................................................................... 95

2

WebCP2003............................................................................................................. 96

3

RemCP2003............................................................................................................. 96

4

RemBridge.............................................................................................................. 96

5

Experimentos.......................................................................................................... 97

Capítulo 5

Conclusiones.................................................................................... 98

Capítulo 6

Futuros desarrollos....................................................................... 100

Capítulo 7 Estudio Económico....................................................................... 103 1

Planificación previa............................................................................................ 103

2

Uso real aproximado del tiempo invertido en el proyecto.......................... 104

3

Valoración económica ........................................................................................ 104

Bibliografía............................................................................................................ 105 Anexo I Manuales de usuario.............................................................................. 107 Capítulo 1

API de RemModbus...................................................................... 108

pfc_dsm.RemModbus Class SerialPort .................................................................. 108 Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.

viii

. Índice

Capítulo 2

Manual de RemModbus............................................................... 112

Capítulo 3

Manual de WebCP2003 ................................................................ 116

1

Entrar en la aplicación............................................................................................. 116

2

Sistema inteligente de interacción........................................................................... 117

3

Interacción simple ................................................................................................... 118

4

Administración del polling y obtención de medidas ............................................... 119

5

Administración de usuarios ..................................................................................... 121 5.1 Editar usuario. ....................................................................................................................121 5.2 Borrar usuario .....................................................................................................................122 5.3 Añadir usuario ....................................................................................................................123

Capítulo 4

Manual de RemCP2003................................................................ 124

Capítulo 5

Manual de RemBridge.................................................................. 126

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


1

Memoria. Índice

MEMORIA


Memoria. Introducción

2

Capítulo 1 INTRODUCCIÓN En la introducción se van a estudiar tanto las soluciones alternativas a ciertas partes del proyecto basadas en otros trabajos previos o en otras tecnologías existentes, como las soluciones tomadas por el equipo de desarrollo. Se recomienda la lectura del resumen ofrecido anteriormente, para tener una visión general del proyecto y facilitar la comprensión de éste.

Como ejemplo, hemos visto anteriormente que uno de los pilares sobre los que se fundamenta este proyecto, consiste en el desarrollo e implementación de un sistema que permite la comunicación de cualquier aplicación con la red Modbus. Aquí veremos por qué este punto es interesante y por qué se ha decidido implantar.

Más adelante veremos los objetivos a alcanzar, con una breve descripción, la metodología de desarrollo del proyecto, sus fases, las herramientas, tecnologías y recursos que se han utilizado durante todo el ciclo de desarrollo e implementación, etc.

En general durante la introducción, distinguiremos entre las dos grandes partes del proyecto:

1. Temas relacionados con Modbus sobre TCP y su programación . 2. Temas relacionados con el CP2003 y su uso remoto.



3

1 Estado del arte

Se establecerá el entorno tecnológico anterior al desarrollo del proyecto, desarrollando además las diferentes soluciones disponibles a los problemas planteados.

Antes de entrar en el tema del funcionamiento de una red Modbus sobre una red TCP/IP o en el dispositivo CP2003, es conveniente describir Modbus: qué es, cómo funciona y para qué se utiliza.

El protocolo Modbus es un protocolo abierto, lo que significa que puede ser utilizado gratuitamente por los desarrolladores. Aprovechándose de esto y de su sencillo diseño y versatilidad, Modbus se ha convertido desde su creación en 1979 en el estándar de facto de entornos industriales, siendo utilizado para la comunicación entre señales de instrumentación o dispositivos de control y un controlador principal o un sistema de recogida de datos, como por ejemplo, y en este caso, un ordenador.

Si tratamos de localizar las competencias de una aplicación Modbus en el modelo OSI, vamos a ver que el protocolo se acomoda en dos niveles,

o

Nivel de aplicación (aplication layer), donde trabajarían los programas que utilizan los dispositivos e interpretan los datos de dichos instrumentos. (Ej: Windmill, Hyperterminal, etc.).

o

Nivel de protocolo (data-link layer), donde se localizaría el intercambio de tramas básicas del protocolo Modbus.


4


APLICACIÓN MODBUS

NIVELES OSI 7

Aplicación

SI

Protocolo de aplicación

6

Presentación

NO

5

Sesión

NO

4

Transporte

NO

3

Red

NO

2

Enlace

SI

Tramas Modbus

1

Físico

SI

RS485 o RS232

Figura 1: Niveles OSI y aplicaciones Modbus

Este protocolo se basa en una arquitectura sin estados Cliente-Servidor (denominados maestro y esclavo respectivamente), donde cada dispositivo tiene un número de esclavo que se utiliza a modo de dirección. Modbus permite ver a cada dispositivo conectado como un banco de registros contiguos. Cada registro tiene una dirección de 16 bits dentro del rango 0x0000 a 0xFFFF, y tiene un tamaño. Dependiendo de cada dispositivo, almacenará un determinado tipo de información (en el caso del CP2003, tensión, intensidad, etc.) o tendrá una determinada función (para el CP2003, activar o desactivar un relé, disparar una alarma, etc.). Modbus representa direcciones y datos mediante big-endian. Esto se traduce en que el bit más significativo es enviado primero, luego a la hora de transmitir una cantidad mayor que un Byte, los 8 primeros bits se enviarán antes (Por ejemplo, 0x1F4E será enviado como 0x1F 0x4E).

Como medio físico de transmisión, el protocolo puede utilizar tanto RS232, como RS485, ambos medios de tipo serie. RS232 es usado para comunicaciones de corta distancia punto a punto (así como RS422, el cual es una extensión “bidireccional” de RS232 para entornos industriales), mientras que RS485, además de permitir distancias mas largas, puede ser utilizado para redes multipunto utilizando el Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.

5


paradigma Maestro-Esclavo anteriormente mencionado. Lógicamente, el medio de transmisión más utilizado, teniendo en cuenta esta información es RS485.

La comunicación se basa en el paradigma Request-Response, de lo que se denomina comúnmente PDU (Protocol Data Unit). El protocolo permite mediante tramas, consultar o actualizar el valor de dichos registros. La trama de petición es recibida por todos los dispositivos de la red, pero solo es procesada si la trama esta dirigida al identificador del instrumento que la recibe, enviando una respuesta modificando tan solo el PDU. En resumen, cada trama de petición obtiene solo una trama de respuesta, a no ser que haya un error de trama, en cuyo caso no se obtiene ningún tipo de respuesta.

Figura 2: Comunicación Modbus

A continuación se muestra una representación sencilla de una trama Modbus:

ID

CMD

INFO

CRC

1 Byte

1 Byte

n Bytes

2 Bytes

Figura 3: Trama Modbus RTU o

ID (1Byte) es el número de esclavo, que hace las veces de dirección.

Es posible que haya dos dispositivos con el mismo slave number dentro de la red, por lo que hay que tenerlo en cuenta a la hora de introducir un nuevo Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.

6


dispositivo, y programar su dirección adecuadamente. Se permite direccionar hasta un máximo de 63 esclavos con RS485. o

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

básicos de órdenes: Lectura/Escritura de/en los registros del esclavo y órdenes de control (reset, start/stop, etc.)

Figura 4: Comandos Modbus

o

INFO (nBytes) definido anteriormente como PDU, contiene la

información necesaria para la ejecución de la orden indicada en CMD. Esta puede estar organizada en dirección del primer byte, y número de bytes a escribir o leer en caso de Lectura/Escritura o podrían ser códigos de subfunciones para el caso de ordenes de control.

o

CRC (2Bytes) Mecanismo de control de errores de transmisión (cyclic

redundancy check)


7


2 Motivación del proyecto 2.1 Modbus sobre TCP

Existe un método para acceder remotamente a la red Modbus vía TCP/IP: el protocolo Modbus/TCP. Éste no es más que una extensión de Modbus, introducida por Schneider Automation, que encapsula el las tramas Modbus sobre tramas TCP para permitir su envío y recepción a través de Internet o una intranet. De igual forma que Modbus, es abierto y se ha convertido en el protocolo de facto para este tipo de comunicaciones. A continuación se va a describir como se encapsularía en Modbus/TCP una trama Modbus de petición o respuesta. Estas tramas poseen una cabecera compuesta por 6 Bytes divididas en tres campos, como se aprecia en el gráfico.

TRAMA

ID

CMD

ID DE PROT

LONGITUD

INFO

CRC

MODBUS

ID TRANS

TRAMA MODBUS

TRAMA MODBUS/TCP

Figura 5: Trama Modbus RTU encapsulada sobre Modbus/TCP

Posición del Byte y su significado

Byte 0 - Identificador de transacción. Copiado por el servidor. Normalmente 0. Byte 1 - Identificador de transacción. Copiado por el servidor. Normalmente 0. Byte 2 - Identificador de protocolo = 0. Byte 3 - Identificador de protocolo = 0. Byte 4 - Campo de longitud (byte alto) = 0.Ya que los mensajes son menores a 256. Byte 5 - Campo de longitud (byte bajo). Número de bytes siguientes. Byte 6 - Identificador de unidad (ID), previamente dirección esclavo. Byte 7 - Código de función Modbus (CMD). Byte 8+ - Los datos necesarios.


8


Las soluciones comerciales que utilizan Modbus/TCP ofrecen dos tipos de arquitectura en función de en que lado se deseen situar los dispositivos maestros, si en la parte Serie o en la parte TCP. La arquitectura más utilizada es aquella en la que los dispositivos maestros, es decir, los dispositivos que solicitan la información de los esclavos, están en la parte TCP.

Modbus Master 1

INTERNET ó

(Cliente)

INTRANET

TCP/IP

Esclavo 1 RS232

Modbus TCP

Modbus RTU

(Servidor)

(Maestro)

Esclavo 2

TCP/IP

RS485 / RS422

Modbus Master 2

Esclavo 3

(Cliente)

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

Para poder implementar el protocolo Modbus/TCP resulta necesario adquirir la pieza fundamental que hace funcionar esta arquitectura, que es un elemento hardware que cumple la función de pasarela entre el protocolo TCP y el protocolo Modbus. Este gateway, normalmente

y dependiendo de la empresa que lo proporcione, suele incluir

embebido un sistema de páginas Web que permite navegar a través de los dispositivos de la red y mostrar el estado de sus registros como si estuviéramos utilizando un terminal de operaciones. Otros gateways son programables, por ejemplo en Java y/o permiten instalar aplicaciones o servidores Web en su interior, optimizando así el uso de las características de un dispositivo concreto al que se conecte.


9


2.2 Uso del CP2003

El Multiconvertidor Programable CP200X es un equipo de la empresa española SACI, que recibe señales de energía de una red eléctrica, las mide y procesa, y las envía a distancia mediante tres salidas de tipo analógico, dos salidas de tipo digital todo o nada y opcionalmente, una salida serie de comunicaciones con enlace hacia un ordenador o dispositivo central de control, accesible mediante el protocolo Modbus.

Las salidas analógicas pueden ser configuradas para representar cualquiera de las variables medidas. Asimismo, las salidas digitales pueden representar o bien impulsos correspondientes a la energía consumida, o bien una señal de alarma sobre alguna de las variables medidas. SACI ofrece por medio de su página Web (http://www.saci.es) una herramienta software para el manejo dentro de la red local del dispositivo. Por otra parte para utilizar esta herramienta es necesario obtener previamente una licencia, de modo que no puede utilizarse de forma gratuita, y no ha podido ser probada.

Red Eléctrica

CP2003

Sistema de Control

Figura 7: Conexión básica del CP200X


10


Datos de información técnica:

El empleo de microprocesador permite un proceso de medida totalmente digital. El Microprocesador controla el convertidor A/D, toma las muestras, las almacena, y las procesa, obteniendo los valores de las variables básicas, de la forma siguiente: Ecuación 1: Ecuaciones de cálculo de medidas

V i = Pi

=

∑V 2, I i 32 i j

∑ (V ,

2

=

* I i , j ) 32

i j

∑ I i , j S i 32 Qi

Pi

=

2

+

2

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 señal de red, entre dos pasos por cero sucesivos. La determinación

de

la

frecuencia

permite

que

el

microprocesador ajuste el tiempo de toma de muestras, de forma que el equipo puede trabajar indistintamente entre los extremos del rango 45 - 65 Hz. Una memoria EEPROM tipo serie se encarga de almacenar los datos de configuración del equipo, tanto en lo que se refiere a datos de usuario, como a los de calibración del equipo. El multiconvertidor además ofrece tres tipos de salida: Serie: La salida de comunicaciones, puede ser bien RS232, o RS485. No esta aislada

respecto de la analógica S2, pero si del resto. Analógicas : Las salidas analógicas se encuentran asimismo aisladas del resto de

circuitos, y disponen de una fuente de alimentación individual mediante convertidores CC/CC. Digitales : Dos salidas digitales a base de relés se pueden utilizar, para envío de

pulsos de energía a distancia, o como señales de contactos maniobrados desde el PLC o PC. Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.


11

3 Motivación del proyecto 3.1 Desarrollo de un entorno para el desarrollo de aplicaciones remotas Modbus

Este primer apartado justificara la creación de un sistema que facilite el desarrollo de aplicaciones remotas en Java, para permitir el acceso a la red Modbus a través de Internet o intranet.

La motivación más importante de esta primera parte del proyecto es que va a permitir a futuros usuarios desarrollar fácilmente aplicaciones que trabajen sobre redes o dispositivos Modbus, sin tener la necesidad de utilizar una solución comercial que incorpore una pasarela, y evitando de esta forma tener que incluir otro dispositivo hardware en la red, con el gasto y las complicaciones que eso implica. Solo será necesario un ordenador típico con Microsoft Windows y un puerto serie típico RS232 ó RS485, para que se conecte a la red y haga las veces de servidor, o de gateway.

Muy importante es también, que no solo se pretende establecer una comunicación, sino que se pretende desarrollar todo un entorno capacitado para recolectar información de la red, y traspasar las fronteras del protocolo ofreciendo servicios de control de acceso y de control y recuperación de errores, cosa que un protocolo sin estados y sin capa OSI de transporte como es Modbus, no posee.

Además se pretende facilitar la labor de los programadores, evitándoles el estudio del protocolo ya desarrollado Modbus/TCP, descrito con anterioridad, que sería necesario para desarrollar cualquier aplicación remota. Muchos ingenieros y desarrolladores de software industrial, no están familiarizados en comunicaciones


12


TCP/IP y ven cómo sus trabajos para la administración de estas redes típicamente industriales, tienen que quedarse limitados al entorno físico de la red.

Gracias a esta utilidad Java, se podrá potenciar el desarrollo de aplicaciones remotas por parte de todos desarrolladores que hemos mencionado antes, ya que pretendemos abstraer al diseñador o programador de todo el entorno de comunicación de manera que no tenga que preocuparse por ningún tema de protocolos de Internet. También podremos asegurar que estos podrán abstraerse de trabajar a nivel de puertos serie. Esto se suele llevar a cabo con una librería de comunicación serie de Java, de la que no hay demasiada documentación, además de no ser intuitiva y no todas sus utilidades funcionan correctamente en todos los entornos. Para facilitar aun más las cosas, se dispondrá de una API que detalle las funcionalidades y operaciones que se pueden realizar en la red. De esta manera, utilizar esta utilidad a la hora de programar será tan fácil como pueda ser utilizar cualquier otra librería de Java mientras programas.

Otra gran ventaja que ofrecerá esta utilidad es el amplio abanico de programas que permitirá desarrollar, ya que de cara al usuario, las entradas y salidas básicas de nuestra aplicación podrán recrear en su ordenador el funcionamiento de una transacción típica Modbus. Esto significa que se podrán realizar desde programas especializados orientados a un dispositivo Modbus en concreto, hasta programas orientados a cualquier instrumento Modbus conectado a nuestra red RS485, pasando por programas de administración de red, o incluso aplicaciones Web como las que 1

ofrecen empresas como Lantronix

2

o Intellicom

en sus gateways Modbus –

Modbus/TCP.

1

http://www.lantronix.com/

2

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 programación de aplicaciones remotas, debemos estudiar en que medida ofrecen ventajas las aplicaciones remotas para redes y dispositivos Modbus.

o

La más evidente ventaja del acceso remoto, es que no es necesario un desplazamiento físico hasta donde esté implementada la red, por lo que inmediatamente se reducirán los costes de transporte y tiempo de todas las operaciones de mantenimiento o control que se realicen normalmente sobre la red o sobre un dispositivo.

o

La gestión de sistemas distribuidos se hace más sencilla usando las tecnologías de Internet disponibles, por lo tanto conseguiremos mejorar este aspecto.

o

Esta tecnología nos brinda también la posibilidad de mejorar el servicio a los clientes. Los tiempos de respuesta se reducirán y podrán desarrollarse nuevos servicios que carecían de sentido en un ámbito meramente local.

o

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

o

Mediante un Standard de comunicación universal como es TCP/IP y un protocolo público Modbus, obtenemos una red realmente abierta, para un intercambio y proceso de datos.


14


o

Se ofrece la posibilidad de realizar conexiones remotas con equipos de campo, pero no olvidemos que también se ofrece la posibilidad de realizar conexiones locales por medio de la LAN (Local Access Network). Es importante resaltar este aspecto, ya que el mercado de portátiles esta dejando de incorporar rápida y progresivamente las conexiones serie tipo RS232, que se venían incluyendo sus productos. La empresa hp (http://www.hp.com) por ejemplo, ya no ofrece este tipo de conexión en sus últimos portátiles, y es muy común ver como los últimos modelos de las principales empresas, ya no implementan este tipo de puertos, que como hemos visto, son muy necesarios en entornos industriales, en medida de que la gran mayoría equipos de campo trabajan bajo protocolos serie, más concretamente, Modbus. Todo esto, e incluyendo la incorporación de tecnologías inalámbricas de acceso a redes Ethernet (WiFi), convierten este tipo de aplicaciones, no solo en una solución a la falta de puertos COM en los portátiles, sino una herramienta cómoda de conexión a redes Modbus sin necesidad de cables.

Cliente #1 TCP/IP

Servidor TCP/IP

Esclavo #1 Modbus

Maestro Modbus

RS485

Esclavo #2 Modbus

Cliente #2 TCP/IP Figura 8: Ventajas wireless aplicadas al mundo TCP - Modbus



15

3.3 Controlador remoto del CP2003

Dos puntos pueden resumir la motivación a la hora de crear una herramienta que se comunique con el equipo CP2003 de SACI:

1. Necesidad de ofrecer un servicio: El origen de este proyecto surge de la necesidad transmitida por el director de obtener un polling remoto de medidas energéticas, sobre una red eléctrica y utilizando el dispositivo CP2003. Este será proporcionado por el laboratorio de la Universidad Pontificia Comillas. Como hemos visto anteriormente, SACI si proporciona una herramienta, bajo licencia, de manejo de su equipo, pero ésta, además de ser de pago, no proporcionaría acceso remoto.

2. Necesidad de probar la herramienta de desarrollo: Desde un punto de vista más personal, esto representa una buena oportunidad para probar la potencia y sencillez del sistema de desarrollo creado con anterioridad, en una aplicación con un uso real, pudiendo así implementar las funciones y utilidades de la API de nuestra herramienta de desarrollo.

Vamos a tratar de exponer un ejemplo típico en el que un control de energía de la red eléctrica como el que ofrece CP2003 puede ser útil. Supongamos que el propietario de un hotel está preocupado por el consumo y la calidad de su servicio, y no sabe cuanto gasto le puede suponer mantener el aire acondicionado en servicio, por ejemplo, durante los días fríos o de invierno. El dueño del hotel supone que si mantiene encendido el aire en estas circunstancias, el consumo será menor que durante el verano o los días calurosos, ya que mucha gente no hará uso de él. Sin embargo también sabe que mantener encendido este servicio para todo el hotel supondría un gasto. Sistemas como el CP2003 pueden ayudar a cuantificar esas suposiciones y ayudar a justificar las decisiones que se tomen. Sin embargo este tipo de operaciones no se llevarían a cabo si el dueño del hotel tuviera que ir al lugar donde esta conectado a la red eléctrica el dispositivo y tomar nota de los datos. El acceso remoto va a facilitar sustancialmente las operaciones administrativas de este tipo.


16


4 Identificación de Necesidades 4.1 Objetivos

A partir de este momento nos referiremos como RemModbus, a la herramienta que se va a crear para permitir y facilitar el desarrollo de aplicaciones Modbus remotas en Java, y como RemCP2003

4.1.1 Objetivos Generales



Desarrollar una aplicación que facilite el desarrollo de aplicaciones Modbus sobre Internet o intranet. (RemModus)



Proporcionar acceso remoto a un conjunto de medidas realizadas al dispositivo CP2003 (RemCP2003).



Desarrollar RemCP2003 utilizando RemModbus.

RemCP200X

RemModbus

Figura 9: Cooperación entre productos finales



17

4.1.2 Objetivos de RemModbus



Conseguir la comunicación básica Modbus: intercambio de PDUs.



Permitir, mediante una instanciación muy sencilla, el acceso de cualquier aplicación Modbus a la red, de forma remota.



Permitir acceso múltiple a la aplicación.



Aplicación escalable.



Diseñar una arquitectura modular que permita incorporar fácilmente varios dispositivos a la red.



Implementar esa arquitectura y permitir comunicar con varios dispositivos



Desarrollar una API que facilite la utilización de RemModbus.



Trasladar a nuestra aplicación de desarrollo todo el potencial y la sencillez de la red Modbus que sea posible.



Establecer un control de acceso sobre la red.



Permitir a las implantaciones utilizar distintos niveles de usuario.



Permitir la implementación de un polling de tramas Modbus sobre la red.



Permitir el acceso a los resultados de dicho polling .



Utilidad de búsqueda automática de dispositivos Modbus conectados a la red.



Ofrecer cierto reconocimiento y recuperación de fallos, necesario para aplicaciones remotas, y no ofrecido por Modbus. Por ejemplo, solucionar la colisión que se provocaría si se ejecutan dos peticiones al mismo tiempo o reponerse ante una situación de no respuesta.



Ofrecer información sobre el estado de la red, o mejor dicho del sistema que administra la red (RemModbus).



18

4.1.3 Objetivos de RemCP2003

Entendamos provisionalmente como RemCP2003 a cualquier aplicación que haga uso de la red de forma remota y en concreto del CP2003, utilizando RemModbus.



Creación del programa que permita, instanciando solo una clase, a cualquier aplicación Modbus ya creada (por ejemplo la ofrecida por SACI para CP200X), acceder a la red administrada por RemModbus y por tanto a sus dispositivos de forma totalmente transparente.



Creación de una aplicación Java RemCP2003.



Creación de un Web Service RemCP2003.



Administración de usuarios.



Implementación de competencias según nivel de usuario.



Implementar la comunicación básica “request-response”.



Dar soporte al trabajo sobre varios equipos CP2003.



Administración de polling en función de las necesidades de cada dispositivo.



Administración del sistema (RemModbus) que maneja la red Modbus, y por tanto administración de la misma



Implementar la mayor cantidad de recursos disponibles en RemModbus para conseguir una aplicación sólida y evaluar su potencia y versatilidad.



19

4.2 Alcance de la aplicación

Se desarrollará en primer lugar la herramienta RemModbus con las funcionalidades necesarias para dar soporte a los requerimientos de una aplicación remota que necesita ser desarrollada. En el ámbito de este proyecto esta aplicación es la que hasta ahora conocemos como RemCP2003.

Dado que uno de los objetivos consiste en probar y evaluar la sencillez, versatilidad y potencial de RemModbus, se ha decidido dividir la segunda parte del proyecto, consistente en la utilización de la herramienta (concretamente sobre CP2003) y en lugar de desarrollar una sola aplicación que haga uso del máximo de funciones posibles, se van a desarrollar tres tipos de aplicaciones modulares que tendrán distintos objetivos.

De esta manera vamos a dividir lo que antes conocíamos como RemModbus en tres aplicaciones modulares:

1. BridgeModbus: Nos va a permitir crear un puente entre un puerto COM virtual del cliente y la red Modbus a la que nos conectaremos remotamente. El objetivo de esta aplicación es permitir que cualquier programa ya desarrollado y preparado para trabajar sólo en ámbito local, pueda hacerlo de manera remota. Consistirá en la aplicación más sencilla de todas a la hora de codificar, ya que solo tendremos que instanciar RemModbus y llamar a uno de sus métodos.



20

2. RemCP2003: Mantendremos el nombre original para aquella aplicación Java que permitirá, en función del nivel de usuario, enviar o solo tramas definidas con anterioridad o además tramas arbitrarias a juicio del usuario.

3. WebCP2003: Para demostrar la flexibilidad de RemModbus, se ha decidido implementar un Web Service basado en él. Mediante esta herramienta Web podremos acceder a parámetros de funcionalidad de la red, conocer su estado, los dispositivos conectados, administrar el polling y administrar usuarios. Todo ello en función también del nivel de usuario.

4.3 Tipología de los usuarios

A partir de la información recopilada hasta ahora ya se puede perfilar a qué tipos de usuarios está dirigido este proyecto.

•

Usuarios de empresa: Cualquier usuario que necesite tomar medidas de energía de una red eléctrica, por ejemplo un gerente para tomar decisiones administrativas en función del consumo de una planta, o un analista interesado en estudiar las variaciones de ciertas medidas como voltaje o intensidad de un entorno eléctrico.

•

Usuarios comunes: Cualquier persona que tenga contratado un plan eléctrico y sospeche que podría ahorrar más con otro más barato, pero no sabe realmente cuanta energía utiliza, y por lo tanto no sabe que plan se adapta mejor a sus necesidades

•

Programadores y desarrolladores industriales o relacionados con el protocolo Modbus.

•

Usuarios de dispositivos o redes Modbus.

•

Usuarios de CP2003.



21

4.4 Restricciones

El sistema presenta algunas restricciones importantes, algunos de ellos no a la hora de desarrollar los productos, pero si a la hora de utilizarlos:

•

RemModbus en su versión Servidor, sólo funciona en Microsoft Windows. El sistema se ha probado satisfactoriamente en XP SP2 y Vista.

•

BridgeModbus, al utilizar la misma tecnología que RemModbus, sólo funciona en Microsoft Windows. El sistema se ha probado satisfactoriamente en XP SP2 y Vista.

•

La base de datos de usuarios debe estar alojada en un servidor MySQL.

•

El servidor MySQL por defecto, se encuentra alojado en de la Universidad de Westminster, Londres (“ jdbc:mysql://rhino.cscs.wmin.ac.uk:3306/3sfe617 ”, Usuario: 3sfe617 , Contraseña: 3sfe617 , nombre de la tabla de usuarios: w1092467_user ).

•

Para un correcto funcionamiento de RemModbus y BridgeModbus, se deben instalar las librerías de comunicación de Java en las carpetas correspondientes de la JRE.

•

Las entradas y salidas de RemModbus se efectuarán en forma de java.lang.String, que comúnmente serán tramas Modbus con el siguiente formato: 0x01-0x04-0x04-0xb5-0x00-0x01…

•

Dado que los PCs que implementan puertos COM, típicamente funcionan sobre RS232, si se desea permitir la conexión de varios dispositivos se debe crear una red RS485. Para ello el laboratorio ofrece convertidores hardware RS232-RS485.

•

Para la ejecución del Web Service de WebCP2003, se necesitará Apache Tomcat.


22


5 Metodología de desarrollo Método incremental o evolutivo. –

Como hemos venido estableciendo, este proyecto se divide en varias fases. Además y como la mayoría de los proyectos cada fase se divide a su vez en distintas subfases, que posiblemente estén formadas por distintas etapas. Se han estudiado varios métodos existentes para ver cuál es la arquitectura de metodología que mejor se adapta a la que hemos utilizado para el desarrollo del proyecto. La que más se aproxima es denominada método incremental o evolutivo, con el cual “se comienza el desarrollo satisfaciendo un conjunto de requisitos, una base

estable.

Las

siguientes

versiones

proveen

los

requisitos

que

faltan,

evolucionando el sistema fase a fase” [L01].

Primero se han definido unos principios mínimos para poder codificar un primer Fase n

modelo del núcleo del sistema sobre el que poder trabajar. Posteriormente se ha dividido

Fase 2 Fase 1

en fases el proyecto estableciendo claramente sus las competencias que debía abordar, y se ha aplicado este modelo a cada una de esas fases, pudiéndose obtener de cada etapa un realizar un primer modelo del núcleo del sistema y codificarlo. Esto se adapta muy bien a nuestras necesidades ya que no teníamos certeza de cómo se desarrollaría la aplicación, ni cómo íbamos a solucionar ciertos problemas de implantación. Por otra parte el modelo evolutivo o incremental, se adapta muy bien a la programación orientada a objetos, y dado que utilizamos Java para su desarrollo, parece ser de nuevo la mejor opción.



23

6 Recursos, herramientas y tecnologías empleadas



Para el desarrollo de en Java se ha utilizado o Java 2 Standard Edition (J2SE) como lenguaje de programación. o NetBeans IDE 5.5.1 como entorno de programación. o NetBeans GUI Builder para el desarrollo de interfaces gráficas de

Java.Swing. o

Librería Java javax.comm para las comunicaciones serie.

o NetBeans Java Runtime Environment (JRE) como entorno de

ejecución. o Notepad ++ 4.5 para ediciones puntuales de código. 

VSPD XP4, para establecer una conexión entre dos puertos virtuales.



Para el acceso a Bases de Datos (BBDD), o

Servidor MySQL para alojar la BBDD

o MySQL Administrator 1.2.12 para conexión, creación y edición de

tablas e información de mi BBDD o MySQL Java Connector 5.1.6 para permitir a la aplicación Java

conectarse a la BBDD e interactuar con ella. 

Para el diseño y planificación de la aplicación, o Jude-UML 1.6.2 para la creación de diagramas. o Microsoft Visio 2002 o Microsoft Project 2002



Para el desarrollo de este documento o Microsoft Office XP o Adobe Photoshop CS2 para la edición de gráficos







24

Se han utilizado varias tecnologías de comunicaciones o

TCP, Ethernet, 10/100BaseT

o

Serie, Modbus, RS485

o

Osciloscopio para el estudio de señales RS232 y RS485.

Para la comunicación Serie, o

CP2003

o

PLCs y pupitre de mando para proporcionar mas funcionalidad al

CP2003 o

Windmill comDebug y Hyperterminal para la captura e interpretación

de tramas Modbus. 



Se han utilizado dos convertidores hardware, o

Convertidor USB – Serial

o

Convertidor RS232 – RS485

Se ha desarrollado tecnología Web Service basada en Servlet y JSP o Apache Tomcat para ejecutar el servidor Web o Adobe Macromedia Dreamweaver CS2 para la edición de las páginas

JSP. o Notepad ++ 4.5 para ediciones puntuales de código. o Adobe Photoshop CS2 para la creación y edición de imágenes.



25

7 Estudio de la arquitectura 7.1 RemModbus y RemBridge

Como con toda aplicación Java se va a precisar de un entorno de ejecución tipo JVM (Java Virtual Machine). También hemos visto en restricciones que estas dos

aplicaciones deben estar montadas sobre Microsoft Windows, debido a que el uso de los puertos COM de unos sistemas operativos (OS) a otros. Con el fin de orientar el producto al mayor número de usuarios posible, se ha pensado que era más útil centrarse en Windows por encima de otros OS como Linux. Es por eso que se ha decidido utilizar la librería JavaX (Java Standard Extension) Java Communications, orientada a Windows. Es necesario disponer de un puerto serie físico en el ordenador que ejecute RemModbus y de dos puertos virtuales serie conectados entre sí en el ordenador que ejecute RemBridge. Un convertidor USB-Serial y una aplicación de administración de puertos virtuales, solucionarían este problema (no se proporcionan). En caso de querer dar soporte a toda una red de dispositivos Modbus, será necesario un convertidor de señal RS232-RS485 (proporcionado por la Universidad).

7.2 RemCP2003 y WebCP2003

Será necesario un entorno de ejecución JVM para estas dos aplicaciones. Se precisará que el ordenador que aloje WebCP2003 no tenga el puerto 3306 bloqueado, ya que las conexiones a la BBDD se realizan por ese puerto. Lógicamente, es necesario al menos un CP2003.


26


7.3 Arquitectura extendida de la aplicación.

Red

CP2003 #1

Cliente 1

Eléctrica RS485

Servidor RemModbus

RS232

CP2003 #2

Convertidor RS232/RS485

Router

10/100BaseT

RS485

TCP/IP Dispositivo Modbus

Cliente 4

Cliente 2

WebCP2003 RemCP2003

Cliente 3

Usando RemModbus

Figura 10: Diseño ampliado de la arquitectura


27

Memoria. RemModbus

Capítulo 2 REMMODBUS

1 Introducción En este capítulo tiene como propósito centrarse en el diseño, fases y programación de RemModbus, ya que a partir de este punto las dos partes del proyecto dejan de tener los suficientes elementos comunes como para ser tratadas por igual.

Como esta aplicación trabajará sobre una red Modbus es interesante concretar un aspecto de Modbus que no se mencionó con anterioridad y que hay que tener en cuenta a la hora de diseñar. Existen dos variantes, con diferentes representaciones numéricas de los datos y pequeñas diferencias en el control de trama. “ Modbus RTU es una representación binaria compacta de los datos mientras que Modbus ASCII es una representación legible del protocolo pero menos eficiente” [19]. Ambas implementaciones del protocolo son serie. El formato RTU finaliza la trama con un suma de Control de Redundancia Cíclica (CRC, 2 Bytes), sin embargo en ASCII se añade un carácter de encabezamiento («:» = 0x3A) y los caracteres CR y LF (Carriage Return y Line Feed , 0x0D0A, que al trabajar con Big Endian de 16 bits se traduce en dos campos de dos Bytes: 0x0D 0x0A) a continuación del PDU. La trama ASCII se finaliza con una suma de Control de Redundancia Longitudinal (LRC, 1 Byte).

‘:‘ (0x3A)

ID

CMD

INFO (PDU)

CR

LF

LRC

Figura 11: Trama Modbus ASCII

Dado que el formato utilizado por SACI para CP2003 es el RTU y ademas es el más extendido, las aplicaciones se han orientado a este tipo de formato, por lo que NO se permite la comunicación Modbus ASCII en este proyecto Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.

Memoria. RemModbus

28

2 Diseño

RemModbus va a estar dividido en dos subprogramas, que funcionarán bajo una arquitectura Cliente/Servidor que se comunicarán entre ellos mediante un protocolo propio diseñado expresamente para RemModbus.

El programa Servidor se encargará principalmente de recibir y validar las conexiones entrantes, así como de la transmisión serie de tramas y la administración del estado de la red. Recordemos que el protocolo Modbus es un protocolo sin estados ni nivel de transporte. Esta aplicación nos va a permitir establecer ciertos principios de control y estado.

El programa Cliente, de cara al usuario, consistirá en una clase a instanciar que permita la utilización y el acceso a la información ofrecida por el Servidor, mediante el uso de sus métodos y de forma totalmente transparente al usuario, en función de las necesidades del usuario.


29

Memoria. RemModbus

2.1

Diseño de la Base de Datos

Como veremos a continuación no se precisa una lógica muy desarrollada para el diseño de este apartado ya que tan solo necesitaremos una tabla en la que podamos albergar un conjunto de usuarios, sus contraseñas, y el nivel que tienen. No obstante se especificará aquí por si se requieren modificaciones posteriores.

Diseño lógico de la Base de Datos

•

w1092467_user

(NAME, PASS, PERMISSION)

El nombre de la tabla está adecuado a las normas de la Universidad de Westminster. NAME

Será el alias del usuario. Se definirá como clave primaria.

PASS

Guardará la contraseña del usuario.

PERMISSION

Nivel del usuario. A discreción de los programadores finales

Definición SQL de las tablas

CREATE TABLE w1092467_user ( NAME

VARCHAR (20) NOT NULL,

PASS

VARCHAR (20) NOT NULL,

PERMISSION

VARCHAR (20),

PRIMARY KEY (NAME);


30

Memoria. RemModbus

2.2

Diseño del protocolo RemModbus

Se ha diseñado un protocolo que se adapte perfectamente a las necesidades de comunicación entre los programas Cliente y Servidor del paquete RemModbus. Esta comunicación comúnmente se iniciará por parte del cliente, que requerirá algún tipo de acción por parte del servidor.

1. Trama de acción



3. Trama de confirmación

2. Proceso

Cliente

Servidor

Figura 12: Protocolo RemModbus

En el ejemplo vemos como un cliente envía una trama RemModbus al servidor pidiéndole algún tipo de acción. Esta acción puede consistir desde un proceso complicado como el de conexión hasta una consulta puntual de un estado concreto de la red, o por supuesto una transmisión de una trama Modbus.

CABECERA

DATOS

LONGITUD

Figura 13: Trama RemModbus

A continuación estudiaremos el diseño y la funcionalidad de las tramas RemModbus. El protocolo esta diseñado para que cada trama enviada, reciba al menos una trama de respuesta por parte del receptor de la trama, ya sea para indicar que la operación ha tenido éxito o para notificar del error. Esto nos ofrece la información necesaria para tener la posibilidad de implementar un sistema de detección y recuperación de errores donde antes no se podía.


31

Memoria. RemModbus

Se permitirán cuatro tipos distintos de operación en el servidor, en función del valor de “CABECERA”, que tendrá un tamaño de 4 Bytes. Si es de tipo: i. ii.

CON, se estará iniciando un proceso de conexión. SYN, se esta enviando o solicitando información al servidor para mantener sincronizados tanto a cliente como a servidor. Las distintas subclases de las tramas de sincronización se abordarán en la parte de programación de este mismo capítulo

iii.

DAT, la información del campo de DATOS será normalmente una trama Modbus, que tendrá como finalidad ser transmitida en la red de destino.

iv.

DAO, estamos hablando de un intento de acceso a la BBDD para consulta o modificación de usuarios.

Los valores comunes a cliente y servidor son todas aquellas tramas cuya cabecera sea de tipo: v.

ACK, o cualquiera de sus variantes: NACK. ACK_DAT, etc.

El campo “LONGITUD” de 4 Bytes, como su propio nombre indica nos va a permitir saber hasta donde tenemos que leer para obtener el resto de la trama. Esto significa que vamos a poder enviar en el campo de “DATOS” hasta 2 32

−

1 Bytes, lo

cual cubre de sobra nuestras necesidades.

Finalmente el campo “DATOS” contendrá la información necesaria para la operación que se precise, ya sea en la parte del servidor como en la parte del cliente.


32

Memoria. RemModbus

2.2.1 Proceso de conexión y establecimiento de usuario: CLIENTE (acción) 0. Establecer conexión sobre puerto de escucha

Intercambio de tramas. Formato: CABECERA (DATOS) 1. CON (usuario + contraseña)

SERVIDOR (acción) 0. Escuchando en el puerto de escucha “well known”

2. Validación de usuario. 4. ACK_CON (puerto + nivel de usuario)

3. Cálculo de Puerto

5. Se termina la conexión con el cliente del puerto well known

5. Establecer escucha en el puerto recibido 6. Escuchando en dicho puerto

4. ACK_DAT (puerto + nivel de usuario)

6. Primer envío de información: Lista de dispositivos conectados.

Figura 14: Establecimiento de conexión en el protocolo RemModbus

Para implementar un sistema que permita la conexión simultánea de varios usuarios a la red se ha optado por un sistema en el cual a cada conexión se le establece un puerto en el servidor, que además nos servirá de identificador. Para resolver el problema de cómo sabe el cliente que puertos están libres en el servidor, utilizamos una pequeña modificación en el concepto de la conexión: el cliente inicia una conexión sobre un puerto well known (conocido de antemano) del servidor, sobre el que tiene la certeza que esta escuchando. A continuación el servidor, tras hacer las validaciones oportunas de usuario (conexión a la BBDD y comprobar si es correcto), si todo ha funcionado bien, enviará una trama ACK_CON con el puerto asignado a la conexión, y el nivel del usuario validado, obtenido de la base de datos. Es decir, se cerrará la conexión sobre el puerto de escucha, y será el servidor el que inicie la conexión sobre el cliente. En caso de que la validación de usuario no sea positiva, se enviará una trama NACK, y no se seguiría con el proceso. Posteriormente el servidor volverá a enviar una trama por la nueva conexión. La trama será en este caso de tipo ACK_DAT y contendrá la última actualización de la lista de dispositivos conectados.


33

Memoria. RemModbus

2.2.2 Otras transacciones cliente – servidor. Lógica de confirmaciones.

Después de comprender el funcionamiento de la lógica de conexión se puede pensar que el protocolo es complejo y poco amigable a la hora de trabajar con el. Sin embargo, el protocolo no solo es fácil de entender como veremos ahora, sino que también es fácil de programar y utilizar, como veremos mas adelante.

Toda la lista de transacciones que veremos más adelante sigue siempre la misma lógica, basada en la trama de confirmación recibida.

0. Realizar operación de tipo CAB en el Servidor



1. CAB (DATOS) 1. ACK_CAB (void)

1. CAB (DATOS) 1. ACK_DAT (DATOS)

1. CAB (DATOS) 3. NACK (void) o NACK_DAT (DATOS)

2. Procesar operación de tipo CAB en el Servidor



Figura 15: Lógica de confirmaciones del protocolo RemModbus

Si la operación en el servidor ha sido satisfactoria, se enviará una trama de confirmación ACK_CAB (donde CAB es el tipo de trama enviada originalmente) en caso de que no se necesite información adicional o ACK_DAT, en caso contrario. Si la operación no ha podido llevarse a cabo por alguna razón, se transmite una trama de tipo NACK, o NACK_DAT, siguiendo la misma lógica.


Memoria. RemModbus

34

2.2.3 Lista de transacciones





Tipo CON: (transacción vista con anterioridad) 

CON + Usuario y Contraseña.



ACK_CON + Puerto

Tipo SYN: 

SYN_POLON: Arranca o detiene el polling . Devuelve el estado.



SYN_POL: Devuelve en que estado se encuentra el polling.



SYN_POLDAT + lista polling: Actualiza la lista de polling en el server.



SYN_CON: Desconecta al usuario del puerto de la conexión.



SYN_FIN: Devuelve la última revisión de los dispositivos conectados.



SYN_FINON: Arranca el proceso de búsqueda de dispositivos. Devuelve el tiempo estimado para la finalización del proceso.



SYN_CAN: Permite al usuario renunciar a la siguiente trama que fuera a recibir.



SYN_ETA: Devuelve el tiempo estimado para que el servidor se quede sin ninguna ocupación, o NACK si ya está libre.


Memoria. RemModbus



35

Tipo DAT: 

DAT + trama: Envía a la red Modbus trama, y devuelve la respuesta de la red. Mediante esta trama si el servidor esta ocupado atendiendo alguna labor administrativa como la búsqueda de dispositivos, se cancela el envío a la red Modbus y se devuelve NACK + ETA (Estimated Time of Arrival).



DAT_ABS: + trama: Funciona de la misma forma que DAT a excepción de que si hay un proceso funcionando, la petición se encola y el cliente debe esperar su turno. Una vez enviada la trama no se puede cancelar la ejecución de la trama.



Tipo DAO: 

DAO_UPD + nombre, campo a cambiar y nuevo valor del campo: Nos permite editar el valor del campo indicado, del nombre de usuario.



DAO_DEL + nombre: Nos permite eliminar el usuario indicado.



DAO_ADD + nombre, contraseña y nivel de usuario: Crea un usuario con los parámetros indicados.


36

Memoria. RemModbus

2.3

Diseño de RemModbus Servidor

Esta versión del paquete RemModbus hará de representante del dispositivo maestro que desee interactuar con la aplicación. Debe ser instalada en un ordenador conectado a la red Modbus, normalmente mediante RS232. Para el uso de varios dispositivos dentro de la red se recomienda utilizar un convertidor de señal RS232RS485 como los que ofrece el laboratorio de la universidad. La aplicación tiene tres partes muy bien diferenciadas, la primera, de acceso a los puertos serie del ordenador, y a la información que se transmita o reciba de ellos, y la segunda, de procesamiento de conexiones entrantes, y una última que interprete las ordenes se reciban de los clientes conectados.

2.3.1 Lógica del enlace físico con los puertos del protocolo Serie.

Diagrama 1: Enlace a puertos serie


37

Memoria. RemModbus

2.3.2 Lógica de conexión de equipos remotos

Diagrama 2: Procesador de conexiones entrantes

2.3.3 Diseño de control de estado de la red.

Para implementar un sistema de control de estado, que permita conocer en todo momento detalles concretos de la red, se va a crear una clase que albergue todo este tipo de información. Adelantamos que el nombre de esta clase va a ser Estado.java . Es imperativo para el correcto funcionamiento de la aplicación que esta clase se mantenga actualizada en todo momento, ya que será de alguna manera la base de datos de la red, y la referencia a la que acudirán otros procesos y programas para realizar sus operaciones. A partir de ahora conviene distinguir entre conexión o uso de la red (Modbus), que será interpretado como uso físico del RS232 o RS485 y conexión y uso del sistema, entendiendo por sistema ‘RemModbus ’. Empecemos por establecer a continuación cuales serán las competencias de esta clase.


38

Memoria. RemModbus



Acceso a la red Modbus. o

Que

tipo

de

proceso

esta

utilizando

la

red

actualmente

(transmitiendo), si es que se da el caso. Entendemos por tipo de proceso, un usuario accediendo a la red, el proceso de polling, o el proceso de descubrimiento de dispositivos.



Administración del polling. Saber en todo momento si, o

Hay intención de hacer polling, aunque no se este ejecutando porque este otro proceso ejecutándose.





o

El polling se está ejecutando.

o

Cual es la lista de tramas que lo conforma

o

Cuales son las respuestas obtenidas a esa lista de tramas

Administración de usuarios. Saber en todo momento, o

Que usuarios están conectados y a través de que puerto.

o

Cuales de ellos desean transmitir.

o

Ofrecer desconexión.

Administración de cola de acceso a la red Modbus. Hay que considerar, o

No todos los dispositivos pueden transmitir. Hay que desarrollar un método de acceso a la red.

o

Ofrecer métodos para sumarse a la cola.


39

Memoria. RemModbus



Administración de los dispositivos conectados o

Ofrecer un sistema común para todos los dispositivos Modbus que permita el descubrimiento de los dispositivos de la red.

o

Estado de dicho sistema. Si está en marcha o no.

o

Que dispositivos están conectados.

o

Tiempo

estimado

para

que

termine

el

proceso

de finding

(descubrimiento) o





Posibilidad de introducir manualmente los dispositivos

Información y actividades relacionadas con el enlace a la red Modbus. o

Obtención de canales físicos de transmisión.

o

Métodos de transmisión y recepción de tramas.

Control de los tiempos de respuesta de tramas a una request sobre un equipo. o

Utilizado para deducir si la red ha contestado a una determinada trama.



Estado de la conexión TCP/IP y Modbus o

Está el sistema conectado a la red o no.

o

Está el sistema escuchando en el puerto de escucha o no.


40

Memoria. RemModbus

2.3.4 Lógica de colas.

Como Modbus no ofrece mecanismo control de envío, ni de acceso a la red, ni de recuperación y retransmisión de tramas, tenemos que buscar una solución para evitar el problema que se plantea ante la situación en la que se transmitan varias tramas al mismo tiempo, o antes de que el primer emisor haya recibido su respuesta. Intentaremos representar el problema real de cualquier red Modbus con varios maestros accediendo simultáneamente, con un ejemplo.

Usuario #1

Dispositivo #1

RS485

Usuario #2

Dispositivo #2

Figura 16: Red Modbus

Hipótesis: El usuario #1 (u1) transmite una trama 0x01-0x01-0x01 a la que en condiciones normales el

dispositivo #1 (d1) contestaría 0x11-0x11-0x11. De la

misma forma el usuario #2 (u2) transmite una trama 0x02-0x02-0x02 a la que en condiciones normales el dispositivo #2 (d2) contestaría 0x22-0x22-0x22.

[1] Supongamos que u1 transmite e inmediatamente lo hace u2. De cara a d1 y d2 se recibiría una sola trama formada por una mezcla aleatoria de los bits de la trama de u1 y de la trama de u2, por lo que aunque los dos dispositivos recibirán la trama ninguno sabrá procesarla y no se obtendrá respuesta.

[2] Supongamos que u1 transmite y d1 reconoce la trama. Mientras u2 ha transmitido y su trama llega a d2 justo después de que d1 reconociera la trama, con lo que d2 también la reconoce. Por lo tanto tenemos otra colisión formada por las respuestas, por ejemplo 0x11-0x22-0x11-0x11-0x22-0x22. Los usuarios no podrán interpretar la respuesta. Además ¿quién recibe la trama? ¿u1, u2, los dos o ninguno?


Memoria. RemModbus

41

Además se puede dar la posibilidad de antes de que u1 reciba la respuesta de d1 y éste ya haya contestado, u2 transmita. Recordemos que RS232 es un medio halfduplex (la información puede viajar en un sentido o en otro, pero no al mismo

tiempo) por lo que debemos evitar esta situación en la solución que ofrezcamos, y hacer que la red Modbus completa (incluyendo RS485) funcione en modo halfduplex.

Si recordamos el aspecto de nuestra arquitectura y la enfrentamos a una típica como la del ejemplo anterior vemos que la principal diferencia reside en que nuestra arquitectura provee a la red Modbus de un solo dispositivo maestro real (RemModbus) al que se conectan los maestros potenciales. Esto nos va a permitir crear un cuello de botella para administrar quién entra a la red en cada momento.

Requerimientos funcionales para el acceso a colas:

R01 – Para conexiones modulares de usuario, que constan de un input y un output, se utilizara un sistema FIFO (First In First Out) R02 – Toda transmisión modular ya transmitida debe terminar su ejecución y esperar a la respuesta de la red. R03 – El proceso de descubrimiento de dispositivos, se considera una acción de actualización del sistema, que debe ejecutarse antes que cualquier proceso que esté en la cola. R04 – Cualquier proceso tiene una prioridad mayor que el polling. Es decir, el polling solo se ejecutará si no hay nada que precise ejecutarse.

A continuación veremos su aplicación en los métodos que acceden a la red: Comunicación Modbus, Descubrimiento de dispositivos y Polling


42

Memoria. RemModbus

2.3.5 Lógica de la comunicación Modbus.

Diagrama 3: Comunicación Modbus

Recordemos que cada trama Modbus transmitida obtiene una o ninguna respuesta en función de si ha sido reconocida y aceptada por el equipo Modbus o no. Este diagrama muestra también la implicación del cliente, desde la recepción de una trama DAT enviada por él, hasta el envío de la respuesta obtenida de la red. Nótese además la implantación de la lógica de la diferencia entre DAT y DAT_ABS explicada con anterioridad. Hay que destacar también la implicación del sistema de colas para el usuario, recordemos, FIFO.


43

Memoria. RemModbus

2.3.6 Diseño de control de obtención de respuestas.

Estudiando el diagrama anterior observamos que la finalización de la aplicación, depende de que la red conteste a la trama, pues el programa quedaría bloqueado en “Recibir trama” hasta que haya respuesta. Esto se debe a la implementación de otro sistema de control de la red que se ha implantado. El objetivo es que si al cabo de un cierto tiempo no se ha leído la trama, supongamos que hubo un error y actuemos en consecuencia. Esto se conseguirá imponiendo un timeout a la instrucción de lectura.

Diagrama 4: Timeout

Vemos que en caso de no recibir nada, creamos una trama ficticia con el valor binario ‘0’, aquí representado en hexadecimal 0x00.


44

Memoria. RemModbus

2.3.7 Lógica del descubrimiento de dispositivos conectados a la red (Finding).

Vamos a definir el proceso de finding como una actualización de estado, para el correcto funcionamiento del sistema, por lo que es se supone que si se ha ejecutado, es porque se sospecha que la lista de dispositivos del sistema ha quedado obsoleta. Por tanto vamos a establecer el siguiente requisito funcional: R05 – El proceso de descubrimiento de dispositivos no puede ser interrumpido por ningún usuario o proceso hasta su correcta terminación.

Diagrama 5: Finding


45

Memoria. RemModbus

2.3.8 Lógica del polling.

A diferencia del finding, el este proceso si que puede ser detenido o interrumpido. De hecho no tiene sentido que no lo sea, ya que es un proceso infinito por definición. La solución que se ha adoptado para permitir este tipo de ejecuciones en nuestro sistema, es aceptar listas de tramas del usuario, y establecer si se ejecutan o no. De la misma forma que se reciben las listas de tramas, se ofrecerá la posibilidad de recuperar una lista con las respuestas obtenidas a esas tramas, por lo que es muy importante mantener un control sobre qué trama request obtiene qué trama response. Como es lógico cualquier transacción o proceso se ejecutará antes que cualquier transacción de polling respetando R04. Además añadimos otro requisito funcional, que se antoja evidente, pero que hay que tener en cuenta a la hora de programar. R06 – El proceso de polling que es detenido por otro proceso o transacción, debe ser reactivado al terminar dicho proceso o transacción.

Diagrama 6: Polling


46

Memoria. RemModbus

2.3.9 Lógica de transmisión de tramas. CRC.

Hemos visto como generábamos un cuello de botella para el acceso a la red y luego invocábamos al envío y recepción de tramas. Hay que recordar que estamos utilizando una modalidad de Modbus llamada RTU, cuya peculiaridad es que termina sus tramas con una suma de control de redundancia cíclica. Se ha de desarrollar una función que calcule y añada este CRC al final de cada trama. Esta función debe de estar preparada para el formato de datos utilizado por el sistema. Además hay que tener en cuenta que no consiste en un típico CRC de 32 bits, sino que es de 16 bits.

Diagrama 7: Cálculo del CRC


Memoria. RemModbus

2.4

47

Diseño de RemModbus Cliente

El objetivo del cliente se concentra en conectarse a la aplicación servidor de RemModbus y hacer uso de sus funciones a través del protocolo RemModbus detallado con anterioridad. Esta aplicación deberá ser instanciada por otra aplicación Java en el ordenador cliente que desea utilizar los servicios de la red que administra RemModbus. Por lo tanto ha de ser codificada de tal forma que su instanciación resulte lo más sencillo posible para el programador. Hay que señalar que RemModbus no tiene en cuenta el nivel de usuario a la hora de ejecutar operaciones, ya que considera que es competencia de los programas que utilicen sus servicios.

Mediante su instanciación se debe poder permitir



Establecer una comunicación Modbus. Consultar el protocolo Modbus para ver los distintos tipos de comunicación (operaciones DAT)



Obtener los datos del usuario, sobre todo el nivel de usuario para poder permitir actuar en consecuencia al programador.



Obtener los equipos conectados de forma pasiva (sin forzar actualización).



Obtener los equipos conectados de forma activa (forzar actualización).



Actualizar las tramas de polling en el servidor.



Obtener resultados del polling.



Obtener tramas de polling actuales del servidor.



Ejecutar y detener polling y/o obtener su estado.



Ejecutar finding y/o obtener su estado. Obtener ETA en caso de que este funcionando el proceso.



Establecer un puente entre un puerto COM del usuario y la aplicación.



Desconexión del usuario.


48

Memoria. RemModbus

3 Programación y pruebas

Antes de comenzar a programar necesitamos instalar las librerías a utilizar:



javax.comm consta de tres archivos. Instalar en las rutas especificadas. - win32com.dll: guardarlo en la carpeta ..\Java\jdk\jre\bin - javax.comm.properties: copiarlo en la carpeta ..\Java\jdk\jre\lib - comm.jar: copiarlo en la carpeta ..\Java\jdk\jre\lib\ext La instalación suele dar problemas en función de a donde está apuntando realmente la JRE o la JDK, y de cuál de ellas se está utilizando para la ejecución. Se recomienda consultar la FAQ de la API de comunicaciones de Java [20]. Esta instalación será obligatoria para el equipo que desee utilizar tanto la versión servidor de RemModbus como mas adelante veremos, RemModbus.



mysql_connector también será utilizado por el servidor RemModbus.



Importar los paquetes necesarios.

Diagrama 8: Organización de RemModbus


49

Memoria. RemModbus

-

pfc_dsm.RemModbus.Inet contendrá las herramientas necesarias para el protocolo RemModbus, por lo que deberá ser importado por cliente y servidor, puesto que ambos utilizan sus servicios.

-

pfc_dsm.RemModbus.DAO incluye la lógica de las conexiones a la BBDD. Puesto que sólo el servidor hace uso de operaciones de este tipo, será el único que precise importarlas.

-

pfc_dsm.RemModbus.Modbus sirve para acceder al protocolo serie y establecer un enlace con él. Debe ser importado por el servidor en cualquier caso y por el cliente cuando necesite crear un puente virtual.

-

pfc_dsm.RemModbus.Utilidades

deben

seguirse

las

mismas

directrices que para pfc_dsm.RemModbus.Modbus.

A pesar de que la API de javax.comm ofrece un sistema de eventos para la recepción y envío de datos a través del puerto serie, se ha descubierto que no funcionaba correctamente en algunos casos puntuales, necesarios para desarrollar la aplicación como estaba disñado. Es por eso que han tenido que ampliarse ligeramente las competencias de la clase Estado.java y bloquear los procesos con bucles en lugar de con eventos. Sin embargo el resultado ha sido satisfactorio.

Durante este capítulo se explicarán únicamente la finalidad o funcionamiento de las funciones o métodos que, o bien no tengan un nombre intuitivo, o bien su desarrollo a la hora de programar tenga algún aspecto interesante. Tampoco se incluirán todas los métodos en los diagramas o en los apartados.

Se ha tomado la decisión de estandarizar cualquier proceso de intercambio de datos entre programas y procesos, independientemente de cómo trabajen internamente. Además se ha optado porque el intercambio de tramas Modbus sea el interpretado generalmente para estas redes. Es decir como suelen utilizarse lógicamente los datos de una trama Modbus.


50

Memoria. RemModbus

Requisitos no funcionales

NF01 – Las comunicaciones entre programas y procesos se realizaran por medio de cadenas de caracteres, enviándolas y recibiéndolas como objetos java.lang.String.

NF02 – Elementos de una lista se enviarán separados por el carácter ‘&’ o por el juego de caracteres ‘---‘ en el caso de la conexión.

NF03 – Las tramas serán enviadas y recibidas en todo el entorno RemModbus como

agrupaciones

de

16

bits

e

interpretadas

como

números

hexadecimales con el siguiente formato: 0xAA donde AA representa el valor hexadecimal.

NF04 – Cada una de estas agrupaciones se separará de la siguiente mediante el carácter ‘-‘.

NF05 – La lógica de separación de NF04 se hará extensible a cualquier juego de elementos de una misma entidad lógica.

NF06 – La aplicación se desarrollara en J2SE.

NF07 – Se usará MySQL para el almacenamiento. Localizado en rhino.cscs.wmin.ac.uk/3sfe617


51

Memoria. RemModbus

3.1 Programación del acceso a la BBDD 3.1.1 Diagrama de clases

Diagrama 9: Conexión a la base de datos

Se ha decido crear, una clase abstracta DAO que se encargue de almacenar la información relativa a la BBDD y otra clase que herede de ella, que se ocupe de las labores administrativas de la base de datos como puede ser


52

Memoria. RemModbus

3.2 Programación del protocolo RemModbus

Para la utilización del protocolo se van a utilizar las herramientas que se han desarrollado para esta parte del proyecto. Estas están alojadas en el paquete Inet [Diagrama 8: Organización de RemModbus], que consiste en tres clases: TramaInet.java, TramaInetIS.java y TramaInetOS.java.

3.3.1 TramaInet.java Nos dará la oportunidad de instanciar las tramas para acceder fácilmente a sus campos. A continuación se muestra la parte del código que codifica el tipo de tramas y el diagrama de clase correspondiente.

public static final int CON

= 29;

public static final int ACK_CON

= 19;

public static final int ACK_DAT

= 39;

public static final int DAT

= 2;

//+trama Modbus. Con finding devuelve ETA

public static final int DAT_ABS

= 1;

//+trama Modbus. Se trans. tb con finding

public static final int SYN_POLON

= 49;

//Pregunta el estado del polling

public static final int SYN_POLRUN

= 48;

//StartStop polling de forma remota

public static final int SYN_FIN

= 46;

//pide la lista de ids

public static final int SYN_FINON

= 44;

//Start finding de forma remota

public static final int SYN_POLDAT

= 47;

//En DAT va la lista de polling

public static final int SYN_POL

= 45;

//pide la lista de poll

public static final int SYN_CON

= 41;

//desconecta al user (logout)

public static final int SYN_CAN

= 42;

//renuncia a la sig.trama respuesta

public static final int SYN_ETA

= 43;

//pide ETA

public static final int ACK_SYN

= 59;

//Ready+lista polling actual u otro

public static final int NACK

= 90;


53

Memoria. RemModbus

public static final int NACK_DAT

= 99;

public static final int MAXDATA

= Integer.MAX_VALUE;

protected int tipo;

//almacena el tipo de trama. uno de los de arriba

protected byte[] datos; //el campo INFO del protocolo Modbus protected int longitud; //hasta donde hay que leer.

Organización de métodos:

Diagrama 10: TramaInet

Cabe destacar la posibilidad de obtener el campo de datos como String o como byte[].

3.3.2 TramaInetIS.java y TramaInetOS.java

Diagrama 11: TramaInetIn y TramaInetOS


Memoria. RemModbus

54

Estas dos clases nos van a permitir establecer los canales por los que vamos a enviar y recibir la información proveniente del protocolo RemModbus.

Gracias a este paquete, nos va a resultar muy sencilla la comunicación con el protocolo Modbus. Lo primero que debemos hacer es crear los TramaInetIS y TramaInetOut de la forma siguiente

Socket in = new Socket(…) //creación de canales tis y tos (entrada y salida) TramaInetIS tis = new TramaInetIS(in.getInputStream()); TramaInetOS tos = new TramaInetOS(in.getOutputStream());

Una vez creados los canales, cada vez que se quiera recibir o enviar una trama, solo habrá que hacer uso de los métodos correspondientes. Respectivamente:

//Ejemplo de lectura de trama RemModbus TramaInet trama = tis.readTramaInet(); //Ejemplo de escritura de trama RemModbus tos.writeTramaInet(new TramaInet(TramaInet.NACK_DAT, “0x00-0x00”)); //En caso de querer ver que tipo de trama sigue sin leerla realmente: int tipoSiguienteTrama = tis.siguienteTipoTramaInet();


55

Memoria. RemModbus

3.3 Programación de RemModbus Servidor

El servidor RemModbus tendrá un aspecto similar al siguiente [Figura 17], desde el que inicialmente podremos en primer lugar, conectarnos a la red Modbus o a la red TCP/IP. En términos de programación se refiere a crear un nuevo Enlace.java y un nuevo Server.java. También podremos ejecutar el polling o el finding. También podremos falsear el proceso de finding si conocemos de antemano las direcciones de 3

los dispositivos conectados .

Figura 17: RemModbus Servidor

3

No se ha implementado ningún mecanismo de detección de errores de formato por lo que hay que

tener cuidado a la hora de insertar las direcciones o el sistema se comportara de forma errática.


56

Memoria. RemModbus

3.3.1 Programación de gestión conexión con protocolo serie: Enlace.java

Diagrama 12: Enlace.java

Se solicita información del usuario, para establecer los parámetros de conexión a la red serie. Los parámetros pedidos son tales como puerto COM al que desea conectarse, velocidad de transmisión, bits de parada, control de flujo, bits de parada, 4

etc. A continuación creará la conexión utilizando la API javax.comm y establecerá los canales de entrada y de salida típicos.

3.3.2 Programación de gestión de conexiones remotas 3.3.2.1 Server.java Se encargara de recibir las conexiones entrantes, decidir si son o no aceptadas y arrancar un servidor personalizado para cada conexión aceptada.

Diagrama 13 Server.java

4

Al crearse una conexión serie, el puerto queda bloqueado no p ermitiéndose más conexiones sobre él Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.

57

Memoria. RemModbus

El servidor de conexiones entrantes está montado sobre un Thread, bloqueado dentro de un bucle infinito en la instrucción 3 1 int listeningPort = 9999 2 ServerSocket hall = new ServerSocket(listeningPort,10); 3 Socket in = hall.accept();

Vemos que Server escucha siempre en el puerto well known ‘9999’. Una vez validado el acceso, se calculara un puerto en el rango [8000 – 8030], en función de los puertos que se estén utilizando. Esto significa que solo aceptaremos hasta 30 conexiones remotas. Si se llega al límite se envía una IOException. Con ese puerto calculado y la dirección IP del cliente, creamos una nueva ServerSession

3.3.2.2 ServerSesion.java

Diagrama 14. ServerSession.java

El constructor de ServerSession es el encargado real de crear la nueva conexión. Una vez creada, envía de acuerdo al protocolo RemModbus la trama de dispositivos conectados. Se arranca el Thread, que queda bloqueado de la misma manera que Server.java. A partir de este punto recibe las tramas del protocolo RemModbus, y actúa en consecuencia tras interpretar el tipo de trama. Típicamente llamara a una función u otra mandando en caso de ser necesario, una modificación sobre Estado.java.


58

Memoria. RemModbus

3.3.3 Programación de gestión de estado: Estado.java

Dada la importancia de esta clase se va a proceder a mostrar todas las definiciones de atributos. Habrá una y solo una instanciación de esta clase, que debe estar presente 5

en todas las instancias que efectúen una modificación de estado . Aprovechando esta situación se añadirán los métodos necesarios para la transmisión de tramas al puesto serie.

public static final int POLLING = 991;

//Para determinar quien

public static final int GETDIRECCIONES = 992;

//esta accediendo a la

public static final int ACCESOMAESTRO = 993;

//red Modbus actualmente

private int acceso;

//(sobre acceso)

private boolean onTCP;

//indica si esta conectado a red TCP

private boolean onModbus;

//indica si esta conectado a red MDBS

//polling\\ private boolean polling = false;

//TRUE si hay intencion de polling.

private ArrayList pollingList;

//Ristra de tramas de pregunta poll

private ArrayList pollingListRespone;// ” de tramas de respuesta polling //formato: "0x01-0x02-0xa3...." los 2 a.l. como manda los NF private ArrayList accessQueue;

//el turno para varios users, etc

private ArrayList usList;

//Lista de los usuarios conectados

private User currentUserModbus;

//Mantener user en poder del acceso.

private ArrayList modbusId;

//Lista de disp Modbus conectados //Se guardan sin 0x

5

Es completamente necesario que cualquier modificación en el estado de la aplicación, se vea

reflejado en la instancia única de Estado.java.


59

Memoria. RemModbus

private boolean findingDone = true;

//Cuando esta parado el finding

private int findingProgress;

//porcentaje completado finding

private Enlace link;

//via de comunicación con MODBUS.

private Thread cuenta;

//Modifican la variable que dice si

private Timeout to;

//la red responde o no a la trama

private boolean timeOver = true;

//Control de respuesta a trama

private boolean readingModbus = false;//control de lectura del COM; private boolean tramaOutReady = false;// se ha leido 1 trama completa? private Trama tramaToSend, tramaReceived;

private Polling poll;

//Polling

private Thread pllng; private boolean pollRunned = false;//true si se ejecuto una vez //para no rehacer la inic y tener 2 private UserDAO udao;

//para acceder a los datos de users

Puesto que esta clase implementa más de 50 métodos, vamos a pasar a explicar sólo una de ellas a modo de ejemplo de uso de Estado.java public void setFindingProgress(int i){ findingProgress = i; } public int getFindingETA(){ return (((255-findingProgress)*to.getTimeout())/100); //en segundos } private int getFindingProgress(){ return (((findingProgress + 1)*100)/255); }

Este ejemplo concreto se permite obtener el tiempo estimado que tardará el finding en terminar de ejecutarse. Este proceso va actualizando el valor de findingProgress, así al pedir el progreso o el ETA del finding obtendremos un valor actualizado.


60

Memoria. RemModbus

3.3.4 Programación de colas

Este proceso se basa en la misma forma de proceder que en el ejemplo anterior de petición de progreso y ETA del finding. Los procesos que quieren transmitir, se añaden en una posición determinada de una cola como se vio en el apartado de diseño. Los procesos que optarán a transmitir son una comunicación modular Modbus iniciada por el usuario, o un proceso de polling o finding. - Proceso de polling. Para cada trama que quiera enviar, while( !estado.getPollingIntention() || estado.getAcceso() != Estado.POLLING || !estado.getQueue().isEmpty()) {/*NO HACER NADA*/ try{Thread.sleep(500);}catch(Exception e){}} //estado.setAcceso(Estado.POLLING); //estado.setPollingOn(true); estado.addUserToQueue(u); //LOGICA POLLING + ENVIO estado.leaveQueue();

- Comunicación modular (request-response) estado.addUserToQueue(usuario); estado.setAcceso(Estado.ACCESOMAESTRO); //LOGICA DE ENVIO y RECEPCION if(estado.getPollingIntention()) estado.setAcceso(Estado.POLLING); else estado.setAcceso(0); estado.leaveQueue();


61

Memoria. RemModbus

- Proceso de finding

estado.isFindingDone(false); if(estado.getAcceso() == Estado.ACCESOMAESTRO){ if(estado.getPollingIntention())

{

try{ estado.addUserToQueue(u,2); }catch(Exception ex){ estado.addUserToQueue(u,1); }estado.setAcceso(Estado.GETDIRECCIONES); }else estado.addUserToQueue(u,1); }else estado.addUserToQueue(u); if(estado.getAcceso() == Estado.POLLING){ estado.setAcceso(Estado.GETDIRECCIONES); } }while(((User)estado.getQueue().get(0)).getPort() != -2){} estado.setAcceso(Estado.GETDIRECCIONES); estado.isFindingDone(false); //LOGICA INTERNA if(estado.getPollingIntention()) estado.setAcceso(Estado.POLLING); else estado.setAcceso(0); estado.leaveQueue(); estado.isFindingDone(true);

Para más información, referirse a los comentarios del código.


62

Memoria. RemModbus

3.3.5 Programación de comunicación Modbus y control de obtención de respuestas.

El envío de tramas se hará directamente sobre un método de Estado.java enviarTrama(String trama) utilizando las herramientas mostradas, sin embargo la recepción se hará en un nuevo Thread ReceiveTrama.java

Diagrama 15: ReceiveTrama.java

Se ha establecido durante el diseño que para controlar la falta de respuesta de la red se debía de incorporar un timeout a una instrucción. Evidentemente eso no es posible en Java de forma directa, ni en ningún lenguaje de programación. Empezaremos a manejar los parámetros necesarios en la ejecución de ReceiveTrama.java desde la función recibeTrama() de Estado.java: //EJECUCION DEL THREAD RECEIVETRAMA.JAVA DESDE ESTADO.JAVA\\ this.timeOver = false; //Aqui controlaremos el timeout ó si hay respuesta antes\\ if(!this.getReadingModbus()){ ReceiveTrama rt = new ReceiveTrama(this); Thread recibela = new Thread(rt); //recibela SOLO escucha y crea tramas REALES. recibela.start(); } //bloqueamos: while(timeOver instruccion”

==

false

&&

tramaOutReady

==

false)

//”Timeout

de

{/*ESPERAMOS*/}


la

63

Memoria. RemModbus

Para poder continuar la ejecución se tendrá que modificar uno de los dos valores timeOver o tramaOutReady, ReveiveTrama realizará las siguientes operaciones sobre los atributos de control de respuesta de la instancia de Estado.java (a partir de este momento, se conocerá simplemente como estado) para acabar modificando tramaOutReady.

//INTERIOR DEL THREAD RECEIVE TRAMA\\ tramaReceived = new Trama(); estado.setTramaOutReady(false);

//modificacion de tramaOutReady

//trata de leer trama //en caso de leer algo estado.setTramaReceived(tramaReceived); estado.setTramaOutReady(true);

//modificacion de tramaOutReady

Paralelamente a la ejecución de este hilo se ejecutará desde él, otro Thread Timeout.java,

Diagrama 16: Timeout.java

//EJECUCION DE TIMEOVER.JAVA\\ estado.setTimeOver(false);

//modificacion de estado.timeOver

try{ sleep(time);


64

Memoria. RemModbus

}catch (InterruptedException ie){ System.out.println("Fallo de Timeout");

} if(!outdated){ estado.setTimeOver(true);

//modificacion de estado.timeOver

}

Donde time está establecido como 3000 ms, tiempo de sobra para que se realice una transacción de ida y vuelta Modbus, y modificará el otro valor de estado timeOver, que tiene bloqueada la ejecución. Una vez modificado uno de los dos atributos, continuaria la ejecución.

//CONTINUA LA EJECUCION EN ESTADO.JAVA\\ to.isOutdated(true);

//modifica Timeover.java: timeover ya no es util

if(!tramaOutReady) tramaReceived = new Trama("0x00");

Si se leyó algo de la red Modbus antes de que acabara Timeout, continuaría la ejecución despreciándose el timeout. En caso contrario se crea una trama falsa.


65

Memoria. RemModbus

3.3.6 Programación del finding: FindDevices.java

Sigue el proceso típico:

-

Comienzo: Modificación de atributos implicados en estado

-

Desarrollo: Lógica + Modificación de atributos implicados en estado

-

Finalización: Modificación de atributos implicados en estado

Lógica Dado que manejamos un campo de dirección o número de esclavo de 16 bits (recordemos su representación lógica en hexadecimal: 0xAA) vamos a tener 216

−

1=

255 direcciones posibles, de las que sabemos que 0xC7 y 0x00 no están disponibles.

Se creará un bucle desde i = 1 hasta i < 256 donde en cada iteración se enviará una trama de prueba para ver si se obtiene respuesta. En caso afirmativo el valor hexadecimal de el contador i se guardará en el ArrayList de dispositivos conectados.


Memoria. RemModbus

66

3.3.7 Programación del polling

Sigue el proceso típico:

-

Comienzo: Modificación de atributos implicados en estado

-

Desarrollo: Lógica + Modificación de atributos implicados en estado

-

Finalización: Modificación de atributos implicados en estado

Lógica Trabajamos con dos ArrayList paralelos, uno con las tramas request y otro con las response. Leemos en orden del ArrayList de request y guardamos el índice en el que

esta esa trama. Posteriormente la enviamos y recibimos la response que introducimos el índice que obtuvimos anteriormente en el ArrayList correspondiente.

Puede darse el caso de que se haya cambiado el ArrayList sobre el q trabaja el Iterator que estemos trabajando con información falsa. Esta situación se soluciona actualizando un boolean en estado que indique que la trama ha cambiado, y, al final de cada envió de trama en polling hacer la siguiente comprobación

if(estado.isTramasPollingChanged()){ tramasPolling = estado.getTramasPolling(); it = tramasPolling.iterator(); tramasPollingOut = new ArrayList(); }


Memoria. RemModbus

67

3.3.8 Programación del CRC

El método de cálculo de CRC está localizado en la clase Trama, del paquete pfc_dsm.Modbus. El propio método tiene un sistema para detectar si el CRC se ha incluido previamente en la trama, no añadiéndolo por tanto. Esto es útil sobre todo para la utilización como puente del sistema.

Se han tenido muchos problemas con la programación de esta suma de verificación. Los diagramas no eran suficientemente claros y no se tenía conocimiento del funcionamiento de los operadores de datos. Finalmente se optó por utilizar cadenas binarias representadas sobre Strings. Para facilitar la comprensión del método se muestran los dos campos del CRC que daría como resultado la trama 0x3F-0x63 0x3f ----------------------------------1111111111000000 tiene un 0 en vuelta0. desplazo todos los bits a la derecha 0111111111100000 0111111111100000 tiene un 0 en vuelta1. desplazo todos los bits a la derecha 0011111111110000 0011111111110000 tiene un 0 en vuelta2. desplazo todos los bits a la derecha 0001111111111000 0001111111111000 tiene un 0 en vuelta3. desplazo todos los bits a la derecha 0000111111111100 0000111111111100 tiene un 0 en vuelta4. desplazo todos los bits a la derecha 0000011111111110 0000011111111110 tiene un 0 en vuelta5. desplazo todos los bits a la derecha 0000001111111111 0000001111111111 tiene un 1 en vuelta6. desplazo todos los bits a la derecha y XOR con 0xa001 1010000111111110 1010000111111110 tiene un 0 en vuelta7. desplazo todos los bits a la derecha


Memoria. RemModbus

68

0101000011111111 ----------------------------------0x63 ----------------------------------0101000010011100 tiene un 0 en vuelta0. desplazo todos los bits a la derecha 0010100001001110 0010100001001110 tiene un 0 en vuelta1. desplazo todos los bits a la derecha 0001010000100111 0001010000100111 tiene un 1 en vuelta2. desplazo todos los bits a la derecha y XOR con 0xa001 1010101000010010 1010101000010010 tiene un 0 en vuelta3. desplazo todos los bits a la derecha 0101010100001001 0101010100001001 tiene un 1 en vuelta4. desplazo todos los bits a la derecha y XOR con 0xa001 1000101010000101 1000101010000101 tiene un 1 en vuelta5. desplazo todos los bits a la derecha y XOR con 0xa001 1110010101000011 1110010101000011 tiene un 1 en vuelta6. desplazo todos los bits a la derecha y XOR con 0xa001 1101001010100000 1101001010100000 tiene un 0 en vuelta7. desplazo todos los bits a la derecha 0110100101010000 0110100101010000 01010000 0110100 0x50 0x69

Nótese que del resultado final se divide en dos cadenas de 8 bits y se cambian de posición.


69

Memoria. RemModbus

3.4 Programación de RemModbus Cliente

Figura 18: RemModbus Cliente

RemoteConnection.java es la única novedad que presenta el cliente frente a las clases del servidor. Implementa todo lo necesario para la utilización del sistema: conexión, funciones del servidor, recuperación de estado del servidor, comunicación modbus, etc. Muchos de estos métodos que implementa como String modbusCommunication (String trama) son los mismos que se utilizan en el servidor, ligeramente adaptados. Para la implementación de puentes por ejemplo se utiliza una versión modificada de ese mismo método modbusCommunication, que consiste en envolver ese método en su

homonimo

del

servidor,

pero

invertido.

De

ahí

el

nombre

reverseModbusComunication():

Envía trama

Recibe trama

Figura 19: modbusComunication (server)

En el servidor este método simplente envía una trama a la red serie y recibe su respuesta


70

Memoria. RemModbus

Recibe

Envía

Recibe

Envía

trama

tramaInet

tramaInet

trama

Figura 20: reverseModbusCommunication (cliente)

La función para el cliente funciona inicialmente de la forma inversa. Escucha en un puerto, y lo que recibe lo reenvía utilizando modbusComunication del cliente, la cual invoca al método anteriormente mostrado [Figura 19], que tiene el mismo nombre. Se ejecuta en el servidor y se obtiene la trama que es devuelta al cliente en “recibe tramaInet” del gráfico. Finalmente esta trama se envía al puerto COM desde el que se recibió la trama original.

4 API RemModbus

Se ha desarrollado una API siguiendo la estética de las APIs de Java. Para mas información, se encuentra en la parte de Manuales de Usuario. Consulte el índice.


Memoria. WebCP2003, RemCP2003 & RemBridge

71

Capítulo 3 WEBCP2003, REMCP2003 & REMBRIDGE

1 Introducción En este capítulo tiene como propósito centrarse en el diseño, fases y programación de las aplicaciones que hacen uso remoto de la red Modbus mediante RemModbus.

No se prestara demasiada atención al diseño y programación de los programas RemModbus2003 y RemBridge, ya que no presentan ningún tipo de complicación o entramado a ese nivel, y se limitan a simplemente a instanciar la clase RemoteConnection y utilizar los métodos no utilizados directa o claramente por Web2003.

Por otro lado tenemos Web2003, que sí que es un sistema que consta de un completo diseño y una buena programación. Está basado en el acceso a la red Modbus a través de RemModbus como las otras, pero con la peculiaridad de que está montado sobre un Web Service y ofrece sus servicios a través de un simple navegador Web, incluso desde una PDA o un teléfono móvil.



72

2 Requerimientos funcionales

[R01] Un usuario debe tener asignado un nivel. ‘Owner’ (nivel alto) ó ‘Subscriber’ (nivel bajo). [R02] Solo podrán acceder al sistema los usuarios registrados en RemModbus. [R03] Todo usuario del sistema sin nivel se le asignara el nivel ‘Subscriber’ para la sesión. [R04] El sistema debe mostrar los dispositivos conectados para todos los usuarios. [R05] El sistema debe ofrecer una forma de establecer unas determinadas tomas de medida para que el usuario añada o quite las que desee [R06] Solo los usuarios de nivel alto pueden modificar que tomas de medida se deben tomar en el servidor (polling) [R07] Cualquier usuario independientemente de su nivel puede ver el estado de la toma de medidas 6

[R08] Un ‘Owner’ debe poder administrar los usuarios de RemModbus. [R09] Un ‘Owner’ debe poder ejecutar el proceso de descubrimiento de dispositivos [R10] Cualquier usuario puede detener o arrancar el polling [R11] El sistema no debe dejar arrancar un polling vacío. [R12] El sistema debe mostrar cuándo esta ocupado el servidor, actualizando los dispositivos conectados, y el tiempo estimado hasta que vuelva a quedar libre. [R13] Todo usuario debe tener opción de consultar información a cerca de los dispositivos conectados. [R14] Todo usuario debe tener opción de desconectarse de RemModbus. [R15] El sistema reconocerá situaciones en las que se pueda estar manejando información obsoleta, y ofrecerá al usuario la opción de actualizarla

6

Administrar: Dar de alta nuevos usuarios, borrar usuarios, modificar usuarios



73

3 Requerimientos no funcionales

[NF01] La aplicación debe validar la información [NF01] La aplicación debe utilizar Apache Tomcat como servidor. [NF01] La aplicación debe ser desarrollada en JSEE. [NF01] La aplicación debe utilizar tecnología basada en Servlets [NF01] Las páginas mostradas deben ser JSP

4 Modelo de dominio

Diagrama 17: Modelo de dominio WebCP2003

El diagrama superior muestra los conceptos básicos del dominio del problema así como las relaciones más importantes entre las entidades principales.



74

5 Diagrama de casos de uso

Diagrama 18: Casos de uso WebCP2003

Se han plasmado las acciones que pueden realizarlos distintos tipos de usuario en función de su nivel, a partir de la información plasmada en los requerimientos funcionales. Se describe un caso de uso para la ayuda a su interpretación. “Todo usuario de tipo Owner tiene opción de añadir una medida al polling, pero un usuario de tipo Subscriber no”


75


6 Descripción de los casos de uso

Login

Actor principal

Usuario

Actor secundario

-

Condiciones

-

previas Trigger

Submit del usuario

Escenario principal

Variaciones

1

El sistema muestra la página de acceso

2

El usuario rellena usuario y contraseña

3

El sistema reenvía a la página principal

2a. El usuario no rellena todos los huecos 2b. El usuario / contraseña son incorrectos

Excepciones

1

El sistema muestra página de error

2

El usuario confirma

3

Vuelta a 1

2a La conexión con RemModbus no está disponible •


•

El usuario confirma

•

Vuelta a 1

Logout

Actor principal

Usuario

Actor secundario

-

Condiciones

-


76


previas Trigger

Selección del usuario

Escenario principal

Excepciones

1

El usuario pulsa Logout

2

El sistema reenvía a la página de login



•

El usuario confirma

•

Vuelta a 1

Ver dispositivos Modbus

Actor principal

Usuario

Actor secundario

-

Condiciones

-

previas Trigger Escenario principal

Operación de Servlet 1

El sistema muestra la página de bienvenida con los usuarios conectados

Variaciones

1a. No hay dispositivos conectados 1b. El servidor se está actualizando 1

El

sistema

muestra

el

(los)

correspondiente(s) en la misma página y

aviso(s) ofrece

actualizar el estado 2

El usuario confirma

3

Vuelta a 1

1a.2a. El usuario no confirma 1b.2a. El usuario no confirma


77


1

Excepciones

No se actualiza hasta la siguiente acción de servlet.



•

El usuario confirma

•

Vuelta a pagina de inicio

Ver medidas de un dispositivos Modbus

Actor principal

Usuario

Actor secundario

-

Condiciones

-

previas Trigger

Selección de usuario

Escenario principal

1

El usuario elige un dispositivo de la lista de dispositivos

2

El sistema muestra la página del dispositivo con las medidas

Variaciones

-

Excepciones



•

El usuario confirma

•


2a. La información puede estar obsoleta 2b. El servidor se está actualizando •

El

sistema

muestra

el

(los)


aviso(s) ofrece

actualizar el estadoEl usuario confirma


78


Editar medidas de un dispositivos Modbus

Actor principal

Usuario

Actor secundario

-

Condiciones

Estar en la página de dispositivo

previas Trigger

Usuario Owner Selección de usuario

Escenario principal

1

El usuario elige una medida de la lista de medidas para observar o dejar de observar

2

El sistema muestra que se ha modificado el polling. Cada vez que se muestre una página se debe de ofrecer la opción de actualizarlo en el servidor o de deshacer los cambios

Variaciones

-

Excepciones



•

El usuario confirma

•



El

sistema

muestra

el

(los)


aviso(s) ofrece



79


Actualizar polling en el servidor

Actor principal

Usuario

Actor secundario

-

Condiciones

Usuario Owner

previas Trigger


Escenario principal

1

El usuario elige una medida de la lista de medidas para observar o dejar de observar

2

El sistema lo actualiza y retira el mensaje de polling modificado.

Variaciones

-

Excepciones



•

El usuario confirma

•


1b. La información puede estar obsoleta 1c. El servidor se está actualizando •

El

sistema

muestra

el

(los)


aviso(s) ofrece


Administrar usuarios

Actor principal

Usuario

Actor secundario

-


80


Condiciones

Usuario Owner

previas Trigger


Escenario principal

1

El sistema muestra que el usuario tiene permisos para administrar usuarios

2

El usuario selecciona la opción

3

El sistema muestra los usuarios, contraseñas y permisos.

4

El usuario realiza alguna actualización

5

El sistema ejecuta la decisión del usuario y refresca la página.

Variaciones

-

Excepciones



•

El usuario confirma

•



El

sistema

muestra

el

(los)


aviso(s) ofrece

actualizar el estadoEl usuario confirma 5a. Fallo de la base de datos •


•

El usuario confirma

•



81


Start/Stop de Polling

Actor principal

Usuario

Actor secundario

-

Condiciones

-

previas Trigger


Escenario principal

1

El sistema muestra la opción de arrancar o parar el polling en función de como esté, siempre que no esté vacío.

2

El usuario selecciona Start/Stop

3

El sistema ejecuta la operación y refresca la página

Variaciones

-

Excepciones



•

El usuario confirma

•


2a. La información puede estar obsoleta y el polling haber sido arrancado o detenido por otro proceso. •

El sistema comprueba el estado del servidor y lo compara con el de la aplicación antes de continuar con el cambio de estado

2b. El servidor se está actualizando •

El

sistema

muestra

el

(los)


aviso(s) ofrece



82


Start de Finding

Actor principal

Usuario

Actor secundario

-

Condiciones

Usuario Owner

previas Trigger


Escenario principal

1

El sistema muestra la opción de arrancar el finding si tiene sospecha de que está obsoleto.

2

El usuario selecciona Start

3

El sistema ejecuta la operación y refresca la página

Variaciones

-

Excepciones



•

El usuario confirma

•


2a. La información puede estar obsoleta y el finding puede haber sido arrancado o detenido por otro proceso. •

El sistema comprueba el estado del servidor y lo compara con el de la aplicación antes de continuar con el cambio de estado

Hay bastantes más casos de uso pero dado que todos siguen la misma lógica no se añadirán más a este documento.



83

7 Diagramas de secuencia A continuación se mostraran los diagramas de secuencia de los procesos más importantes y una breve explicación de los mismos si procede.

7.1 Procesos de login y logout

Diagrama 19: Secuencia de Login

El proceso se fundamenta en la creación de un nuevo usuario, su validación en el servidor por medio de RemoteConnection, y su actualización con el permiso. La creación y uso de Display se explicará más adelante. Se envía el control a WelcomeServlet cuyo diagrama de secuencia se encuentra también detallado. Desarrollo en Java de un sistema de acceso remoto a Modbus. Implementación Web y Java del sistema para CP2003.


84

Diagrama 20: Secuencia de Logout

Si un usuario desea desconectarse, deberá poder hacerlo en cualquier página por eso sería interesante incluir un botón de logout en todas las cabeceras de página. El proceso de desconexión o logout es muy simple, ya que no requiere nada más que solicitar la acción a RemoteConnection. A continuación se destruyen user y RemoteConnection para permitir nuevas conexiones y no tener datos de sesión.



85

7.2 WelcomeServlet

En adelante todo forward que se haga sobre WelcomeServlet hará las siguientes operaciones indicadas en el diagrama que sigue

Diagrama 21: Secuencia de WelcomeServlet

La sesión se actualizará en términos de dispositivos conectados y lista de tramas de polling. El sistema Web ofrece un sistema que permite reconocer situaciones potenciales de información obsoleta. Unos ejemplos de situación potencial de información obsoleta, serían



86



que las tramas de polling de medidas no puedan ser interpretadas



que una consulta de petición de número de serie devuelva error



que las tramas de polling se hayan modificado en la aplicación Web y no estén actualizadas



etc.

El sistema se ha diseñado para que la página JSP ‘welcome’ sea una especie de escritorio para el usuario, por lo que la mayor parte del tiempo la invertirá en ella. Es por eso que cualquier aviso ante situaciones como la anterior, o cualquier otro relacionado con las acciones que pueda realizar a cabo el usuario dependiendo de la situación, se realicen en dicha página. A la hora de programar esto lo hemos solucionado con variables verdadero/falso que se estructuran dentro de la clase Display, para mantener más orden en HttpSession. Así por ejemplo mostraremos los mensajes oportunos cuando sea necesario:

<% if (display.isFindingRunning()) {%>

servidor se esta actualizando

<% } %>



87

7.3 Ver medidas de un dispositivo

Diagrama 22: Secuencia de Ver un Dispositivo

Muestra el proceso que se sigue para mostrar las medidas que se están tomando o se pueden tomar del dispositivo seleccionado en la pantalla anterior. En resumen, la JSP encargada de mostrar esa información accederá a los datos necesarios, que ViewDeviceServlet ha preparado para ella. Nótese que puede ser también entendido el diagrama como el diagrama de secuencia de ViewDeviceServlet, desde la instrucción 1.1.1.


88


Interpretando los datos

[Para más información, consultar Anexo 1: CP200X Communication Protocol]

El dispositivo CP2003, aunque es extensible a muchos dispositivos Modbus, ofrece la información en cinco formatos diferentes.

-

ASCII: Como caracteres, enviados en el orden específico. Utilizado para operaciones como lectura del número de serie, etc.

-

BYTE: Ocho bits. Utilizado para parámetros de estado o control

-

WORD: 16 bits, dos Bytes. Enviado como: MSB -LSB

-

LONG: Cuatro Bytes. Enviados como: MSB-[ ]-[ ]-LSB

-

IEEE: Cuatro Bytes. Es el utilizado para las medidas de polling de

7

8

WebCP2003, en el CP200X.

El formato IEEE (coma flotante)

La interpretación y programación de esto ha sido complicada. Se explicará como se ha de interpretar la información de este tipo. Como hemos visto se deben leer cuatro Bytes, que tendrán la siguiente información: BYTE1: SIGNO + EXPONENTE BYTE2: MANTISA HIGH BYTE3: MANTISA MIDDLE BYTE4: MANTISA LOW

7

Most Significative Bit: Bit más significativo

8

Less Significative Bit: Bit menos significativo


89


Hay que tener en cuenta que la posición real de esos Bytes no se ajusta a esa numeración sino que hay que modificar la posición de las parejas de WORDS. Asi por ejemplo el hipotético PDU recibido de una trama 0x0A-0x00-0x43-0x5E, sería de acuerdo a la numeración establecida arriba: 0x43(Byte1), 0x5E(Byte2), 0x0A(Byte3), 0x00(Byte4)

Si SIGNO es el valor binario 0 quiere decir positivo, si es 1 quiere decir negativo. EXPONENTE (EXP) es el exponente, con offset 127.

Para hallar el valor: Ecuación 2: Cálculo de dato IEEE

Value = (− 1

SIGNO

)* 2

EXP −127

 23 i  * 1 + ∑ (2 * M i )  i 1  −

=

Para hallar el valor de los parámetros:

Byte1 7

Byte2 6

SG E7

5

4

3

E6 E5 E4

2

1

0

E3 E2 E1

7

6

5

3

2

1

0

E0 M1 M2 M3 M4 M5 M6 M7

EXPONENTE

MANTISA ->

Byte3 7

4

Byte4 6

5

4

3

2

1

0

M8 M9 M10M11M12M13M14 M15

7

6

5

4

3

2

1

0

M16M17M18M19M20 M21M22M23

<- MANTISA



90

7.4 Editar medidas

Diagrama 23: Secuencia de Editar Medidas del Polling

Se debe tener en cuenta que después de la acción detallada el sistema Web no estará en concordancia con el sistema RemModbus. WebCP2003 mostrará un aviso con dos opciones, deshacer los cambios (recargaría el polling del servidor) o actualizar el polling en el servidor (modificar el polling del servidor). Para estas opciones, como para las demás que se presentan se utilizarán los métodos de RemoteConnection. Consultar la API desarrollada y adjunta para más información.



91

7.5 Administrar usuarios

El diagrama se divide en dos partes, la de acceso a la página de edición de usuarios y la de la administración en si.

Diagrama 24: Secuencia de Administrar Usuarios

Solo si un usuario es Owner se le mostrará la opción de administrar a los usuarios.



92

7.6 Arrancar procesos en el servidor

Diagrama 25: Secuencia de Arrancar Finding

En el diagrama se muestra como ejemplo como funciona la lógica que hace al proceso de finding ser arrancado por el usuario. Se ha escogido este ejemplo porque en esencia hace lo mismo que el proceso de arrancar polling, pero tiene menos operaciones de actualización y la secuencia se ve más clara. Si se presta atención al punto 3, se solicita el estado del finding antes de arrancarlo. Esto se hace por si el proceso ha sido arrancado mientras la página no era refrescada. Hay que tener en cuenta también que normalmente esto no sucederá ya que ese mismo proceso de reconocimiento se hace a menudo, para tener el sistema actualizado el mayor tiempo posible.



8 RemCP2003

Ilustración 1: RemCP2003

Esta aplicación modular tendrá como objetivos 

probar la conexión a RemModbus desde una aplicación Java



probar el uso de una comunicación Modbus (request – response)


93

94


9 RemBridge

Esta aplicación modular será una utilidad que permitirá establecer de forma transparente, un puente RS232 virtual entre un puerto COM del cliente y el puerto que conecta a RemModbus a la red de dispositivos.

Por favor, refiérase al Capítulo 2 RemModbus, apartado 3, Programación y pruebas, para la correcta y siga los pasos de instalación de librerías de RemModbus. Además se precisará crear dos puertos COM virtuales y establecer una comunicación entre ellos. Existen programas ya desarrollados con esa finalidad como VSPD XP4.

Modbus app sobre RemBridge

RemModbus Servidor INET

virtual

COM2 COM3

COM1 TCP/IP

TCP/IP

ESCLAVO

Figura 21: Lógica RemBridge

COM1 y COM2 son puertos virtuales con una conexión virtual entre ellos de manera que lo que envía uno, es recibido por el otro. RemBridge escucha en COM2 y una aplicación Modbus local cualquiera se conecta a COM1 como si el dispositivo estuviera conectado a ese puerto y envía una trama. Al recibir información RemBridge la reenvía por TCP usando RemModbus.RemoteConnection. La trama se procesa como un DAT_ABS (ver diseño de protocolo RemModbus) y se envía la respuesta. RemBridge la recibe y la transmite a COM2, por lo que la aplicación Modbus recibirá esa información de COM1.


Memoria. Resultados/Experimentos

95

Capítulo 4 RESULTADOS/EXPERIMENTOS

1 RemModbus

Es una aplicación que de forma remota y local,

Permite administrar una red Modbus. Proporciona la comunicación básica Modbus: intercambio de tramas. Permite mediante una instanciación muy sencilla, el acceso de cualquier aplicación Modbus a la red, de forma remota. Permite acceso múltiple a la aplicación. Permite varios dispositivos Modbus conectados Ofrece facilidades de uso de Modbus a programadores industriales generalmente Ofrece una documentación en forma de API que facilita aún más la programación y el diseño de aplicaciones Modbus. Permite control de acceso a la red e implantación de niveles de usuario. Permite ejecutar una serie de instrucciones sobre la red y obtener los resultados, algo que hemos llamado `polling`. Ofrece una utilidad de búsqueda automática de dispositivos Modbus conectados a la red, a la que hemos dado el nombre de ‘finding’ Ofrece control y recuperación de errores sobre una arquitectura que originalmente no la tiene (Modbus) Permite un enlace transparente con la red Modbus y con el protocolo RemModbus.



96

2 WebCP2003

Es un servidor Web que esta diseñado para obtener de forma remota información de uno o varios dispositivos CP2003 y además, Administra el polling de medidas a tomar sobre la red Administra el estado de la red Modbus. Se sabe en todo momento que dispositivos tiene conectados, si está funcionando el polling, si un dispositivo no está funcionando correctamente, etc. Administra los usuarios de la red a la que nos conectamos. Considera el nivel de usuario para establecer responsabilidades. Está montado sobre RemModbus.

3 RemCP2003

Programa Java para la ejecución de consultas definidas sobre un CP2003. Implementar la comunicación básica “request-response”.

4 RemBridge

Una instanciación de la utilidad de RemModbus para la creación de puertos virtuales Permite acceder a la red administrada por RemModbus y por tanto a sus dispositivos de forma totalmente transparente. Cualquier aplicación interactuará con la red de forma remota sin saberlo.



97

5 Experimentos

Durante el estudio del diseño de la arquitectura física de la red Modbus, se reparó en el convertidor hardware de señal RS232 a RS485. Surgió la idea de realizar la conversión entre los protocolos por medio de software, por lo que se procedió al estudio preliminar de la señal. Se conectó un osciloscopio al sistema y se estudiaron las tramas capturadas a cada uno de los lados del convertidor. Se observaron que las diferencias entre ambas eran mínimas, ya que lo que variaba de una a otra era el significado de 1 y 0 (tensión en uno, y no tensión en el otro). Aparentemente la intensidad también variaba. Sin embargo implementar este método hubiera supuesto demasiado estudio de la situación y arquitectura de los medios de transmisión, ya que no se sabía si físicamente se podía hacer.

También se ha descartado la idea de la actualización automática de dispositivos conectados, ante un error. Esto es que cuando una trama que se ejecuta sobre un dispositivo no responde, el sistema supone que el registro de dispositivos conectados no está actualizado, y arranca el proceso de finding. Esta función estuvo implantada durante mucho tiempo en el sistema, pero finalmente se retiró de él por dos razones importantes: La primera, que dada la lógica de colas implantada, se ralentizaba el sistema en situaciones en las que no era absolutamente necesario, y la segunda, que se pensó que no era una competencia directa del sistema local.


Memoria. Conclusiones

98

Capítulo 5 CONCLUSIONES Hay que tener en cuenta que se carecía de base alguna acerca de cómo funcionaban los entornos o las comunicaciones industriales antes del desarrollo de la aplicación. Normalmente no son ámbitos de los que un ingeniero informático tenga un buen nivel de conocimiento, por su bajo nivel, muy especializado o al detalle de bit. Es por tanto que se ha requerido mucho tiempo de familiarización con los dispositivos y de estudio de arquitecturas y de alternativas de desarrollo. Se ha gastado mucho tiempo consultando distintas páginas de Internet, con informaciones incompletas o contradictorias, hasta que finalmente se ha tenido un concepto claro. Es por esto que el desarrollo de este proyecto me ha permitido familiarizarme no solo con el protocolo Modbus o con el dispositivo CP2003, sino con todo su entorno. Por ejemplo antes del proyecto nunca antes había utilizado un osciloscopio, un plc o un pupitre de mando, de los que lo más que tenía en el mejor de los casos, era una ligera idea.

He comprobado en mi propio pellejo que la mejor manera de afrontar un problema, es dividirlo en problemas más sencillos, e ir atajándolos poco a poco. Me he divertido haciendo el proyecto y también lo he pasado mal. Me he visto superado por la funcionalidad que debía tener el proyecto, y he sabido cómo solucionarlo.

Se ha mejorado la capacidad de diseño. Además se ha comprobado que el tiempo que se pierde diseñando o elaborando diagramas, se gana a la hora de programar. Un muy buen diseño puede convertirse en una especie de guión para el programador, donde este solo tenga la necesidad de diseñar. El buen diseño en este proyecto ha permitido la creación de utilidades que facilitan la programación. El ejemplo más claro es RemModbus pero esa filosofía la encontramos también a lo largo de todo el proyecto, por ejemplo en la definición de un protocolo de comunicación por Internet.


Memoria. Conclusiones

99

Se han utilizado una gran cantidad de tecnologías lo que ha mejorado mi programación y más concretamente mi manejo de Java, HTML, SQL, CSS, Servlets, etc. Se han aprendido muchas técnicas de programación: el uso de ciertas clases de Java, operadores de datos, etc.

Finalmente se han conseguido cumplir los objetivos planteados inicialmente, y todos los secundarios que han ido surgiendo durante el proceso de diseño y de programación. Personalmente espero que nuestro proyecto pueda se realmente útil, ya sea en su programación, su diseño, o en su concepto, y pueda ser utilizado por otros programadores o usuarios.

Es importante destacar la aportación realizada, de desarrollar una herramienta y su API para desarrollar el objetivo inicial, que consistía simplemente en desarrollar una aplicación que se conectara remotamente un dispositivo Modbus, el CP2003. Esto nos hizo cambiar el alcance de la aplicación, limitando un poco la funcionalidad que tendría inicialmente la aplicación inicial, y desarrollando dos sistemas más modulares que realicen las operaciones sobre el dispositivo, pero añadiendo el valor añadido de RemBridge (Ver Capítulo 3, apartado RemBridge). Con esta aportación ampliamos el rango de utilización a otras aplicaciones Modbus que funcionen sobre otros dispositivos, y facilitamos el desarrollo de otras aplicaciones aumentando considerablemente el grado de abstracción sobre detalles técnicos.


Memoria. Futuros desarrollos

100

Capítulo 6 FUTUROS DESARROLLOS Para poder aseverar que el proyecto se ha terminado y puede ser distribuido quedan cosas por hacer. Cosas que aún no podemos saber. A pesar de que ambas partes del proyecto ya pueden ser utilizadas y ser útiles, es muy posible que muchos desarrolladores a la hora de utilizar RemModbus, por ejemplo, sientan que necesitan más opciones en el servidor. Sé que esto puede suceder, puesto que me ha sucedido a mi mismo, a pesar del buen diseño del sistema, del que se hace gala con anterioridad. Es importante que otros diseñadores y programadores creen aplicaciones reales para ver que necesidades, no pueden ser satisfechas por el sistema. Afortunadamente El diseño de la aplicación es tan flexible y modular que permite añadir fácilmente nuevas funcionalidades.

Por otra parte los programas de utilización de CP2003 están orientados a satisfacer unos objetivos muy puntuales y no implementan toda la funcionalidad del dispositivo, que es mucha. Futuros desarrollos pueden tener en cuenta esta situación, y acabar construyendo un controlador remoto del CP2003, en el que se implementen todas las opciones que ofrece CP2003.

En el caso de RemBridge estamos dependiendo de alguna aplicación que cree un puente y dos puertos COM virtuales, y los conecte entre ellos. Con más tiempo se podría haber incluido esta faceta en el alcance o el ámbito del proyecto. Sería muy interesante desarrollar este punto, aunque el desarrollo de la API para programadores perdería un poco de sentido, o mejor dicho, de utilidad.



101

Además, hay elementos que se ha visto que pueden hacer la aplicación más flexible o más funcional como por ejemplo:

Cambio de base de datos. Actualmente se utiliza y no se ofrece la posibilidad de cambiar, una base de datos en un servidor de Internet, al que se accede mediante un puerto determinado. En algunas redes públicas o compartidas no se podrán realizar conexiones a ese puerto. Adicionalmente hace que la aplicación sea dependiente de un elemento absolutamente externo y estático. Se recomienda implementar un método que permita de forma automatizada: 1. Cambiar la localización de la base de datos. 2. Crear las tablas necesarias. 3. Incluir un registro por defecto, que permita el acceso, del tipo USER=admin, PASS=root, PERMISSION=full Convertir señal RS232 a RS485 por software. Estudiar la posibilidad real de realizar esta conversión. Ver capítulo de Resultados/Experimentos para más información. Permitir comunicación Modbus ASCII [Ver Programación RemModbus]. Llevaría un tiempo cambiar la lógica pero no sería complejo el diseño. Se ofrecen ideas de referencia para su implantación. 1. Establecer protocolo que usa la red en el servidor RemModbus.

2.

Establecer tramas SYN para modificar el protocolo y permitir que el cliente sepa cómo está funcionando el sistema.

3.

Creación alternativa de Trama.java

Establecer utilidades que creen el formato típico de las tramas cuando se comunican entre procesos o aplicaciones, a partir de ArrayList(), Vector(), etc. Y la utilidad inversa. Se podría haber implementado ya pero no se tenía la necesidad ya que cuando surgió la idea ya no era necesario.



102

Estudiar la posibilidad o la utilidad de implementar en el servidor de RemModbus o en una aplicación que se conecte, el envío de e-mails ante medidas tomadas que se hayan preestablecido como peligrosas o dignas de observación. Estudiar si es competencia de RemModbus o de aplicaciones que hagan uso de el. Actualmente se guarda solamente la última respuesta a una trama de polling. Se propone guardar un historial de las últimas respuestas a una misma trama de polling . Esto puede permitir a aplicaciones tipo WebCP2003 realizar gráficas de evolución y permitir un estudio más exhaustivo de la evolución de los resultados del polling. Estudiar si es competencia de RemModbus o de aplicaciones que hagan uso de el.


103

Memoria. Estudio Económico

Capítulo 7 ESTUDIO ECONÓMICO

1 Planificación previa

Ilustración 2: Planificación inicial


Memoria. Estudio Económico

104

2 Uso real aproximado del tiempo invertido en el proyecto



Investigación y aprendizaje: 60 horas



Identificación de necesidades: 15 horas



Diseño: 120 horas



Programación: 100 horas



Pruebas: 20 horas

Teniendo en cuenta que algunas actividades se solapan, el trabajo habrá llevado unas 300 horas. Si a esto le añadimos la documentación, nos moveríamos en torno a las 350 horas.

3 Valoración económica

Se quiere estimar el coste real del proyecto, incluyendo horas de trabajo, software y hardware y material empleado para el aprendizaje.

Equipo (a 3 años): 200 € Software (VSPD XP4): 90 € Horas de trabajo: 7000 € Libros: 100 €

COSTE TOTAL DEL PROYECTO: 7400 €


Memoria. Bibliografía

105

BIBLIOGRAFÍA [1]

Eckel, Bruce Thinking in Java (3rd Edition Revision 4) (2002) Prentice Hall.

[2]

Barranco de Areva, J. Metodología del análisis estructurado de sistemas. (1994) Universidad Pontificia Comillas, Libros de texto (20), Madrid.

[3]

Bowman, J.S.; Emerson S.L.; Darnovsky, M.; The practical SQL Handbook (3 rd Edition)

(1997) Addison-Wesley Developers Press. [4]

Castro Ponce, M. Tecnología de Computadores. (1999) Universidad Pontificia Comillas, Encuadernaciones. Madrid.

[5]

Tejedor, Miguel Redes de Computadores (Vol. 1.) (2004) Universidad Pontificia Comillas, Encuadernaciones. Madrid.

[6]

Tejedor, M.; Castro Ponce, M. Redes de Computadores (Vol. 2). (2004) Universidad Pontificia Comillas, Encuadernaciones. Madrid.

[7]

Rodríguez Mondéjar, J.A.; Fundamentos de Comunicaciones Industriales. Universidad Pontificia Comillas, Practicas de Laboratorio.

[8]

Rodríguez Mondéjar, J.A.; Comunicaciones Industriales Avanzadas. Universidad Pontificia Comillas, Practicas de Laboratorio.

[9]

Jiménez Buendía, M.; Comunicaciones Industriales Universidad Politécnica de Cartagena, Departamento de Tecnología Electrónica.

[10]

Ruiz Olaya, L.F.; Implementación de una red Modbus/TCP (2002) Escuela de Ingeniería Eléctrica y Electrónica de Santiago de Cali, Tesis

[11]

SACI, CP2003 Communication Protocol (2001) SACI, Manuales

[12]

Guías, Manuales y Especificaciones: http://www.modbus.org/specs.php

[13]

http://www.simplymodbus.ca/FAQ.htm


Memoria. Bibliografía

[14]

http://jamod.sourceforge.net/kbase/protocol.html

[15]

http://www.rtaautomation.com/modbustcp/index.html

[16]

http://www.intellicom.se/ModbusTCP_overview.shtml

[17]

http://java.sun.com/products/javacomm/reference/api/index.html

[18]

http://java.sun.com/j2se/1.4.2/docs/api/

[19]

http://es.wikipedia.org/wiki/ y http://en.wikipedia.org/wiki/

[20]

http://java.sun.com/products/javacomm/reference/faqs/index.html

106


Anexo I Manuales de usuario. Bibliografía

107

ANEXO I MANUALES DE USUARIO


Anexo I Manuales de usuario. API de RemModbus

108

Capítulo 1 API DE REMMODBUS Package pfc_dsm.RemModbus

Class Summary RemoteConnection

A remote connection with a RemModbus application

pfc_dsm.RemModbus

Class SerialPort java.lang.Object pfc_dsm.RemModbus

public class RemoteConnection Provides full access, for use and administration, for implementations of the RemModbus server application. Please refer to the official documentation for further generic or specific information.

Author: Daniel Segura Martínez

Field Summary static int

MAIN_PORT

Port number where the server receive incoming connections



109

Constructor Summary RemoteConnection(String ip, String user, String pass)

Creates a new connection with the RemModbus server application.

Parameters: – the ip direction where the RemModbus server app is located. user – nickname or login name. pass – password of the user. ip

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: – 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 modbusIn

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: – 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 com

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: – the frame list to be executed in the server. It needs to have the followinf format: pollList

“0x01-0x02-0xa0&0x02-0x02-0xa0&0x01-0x32-0xa0”…


Anexo I Manuales de usuario. Manual de RemModbus

112

Capítulo 2 MANUAL DE REMMODBUS Este capítulo contendrá una breve descripción del servidor RemModbus y su manejo.

Ilustración 3: RemModbus Servidor

Para empezar a administrar la red Serie y las conexiones entrantes debemos pulsar sobre los botones de conexión a red Modbus y red TCP/IP. Es importante que ambos botones se activen para un correcto funcionamiento del servidor. Al pulsar sobre el primero de ellos, se abrirá la ventana que se muestra a continuación. Sobre ella tendremos que elegir bajo qué parámetros vamos a controlar la red Modbus. (Velocidad de transmisión, bits de parada, puerto COM que proporciona la conexión a la red, etc.)



113

Ilustración 4: Configuración de la conexión Modbus

Mediante el menú desplegable “Menú” de la parte superior de la aplicación tendremos acceso a los procesos de finding y polling. El menú “Administración” debe ser manejado con cuidado ya que permite modificar parámetros internos del programa.

Ilustración 5: Menú Administración



114

La primera opción nos permitirá introducir manualmente los dispositivos que están conectados a la red. Esto puede ser muy útil si no se quiere esperar al proceso de descubrimiento de dispositivos, pero es necesario conocer el número de esclavo de los dispositivos de antemano.

Ilustración 6: Introducir direcciones manualmente

Para modificar el resto de las opciones del menú se abrirán ventanas similares a la anterior. La segunda opción nos va a permitir limitar el rango de direcciones en las que buscar con el finding. Por ejemplo, si el administrador de la red sabe que todos sus dispositivos se encuentran entre el 0x00 y el 0x0F, no tiene por que esperar a que busque también desde el 0x10 al 0xFF. La última de las opciones de este menú sirve para decidir cuánto deseamos esperar antes de suponer que la red no contestará a la trama.



115

Ilustración 7: RemModbus funcionando

RemModbus se estructura en 5 ventanas principales, cada una con una finalidad informativa. La primera muestra la actividad local e interacción con la red Modbus, mientras que la de debajo suyo (Acceso Remoto) se ocupa de las acciones llevadas a cabo por los usuarios conectados mediante los programas que funcionan con RemModbus. En las ventanas de la derecha vemos los detalles de los procesos de polling y finding , y los usuarios conectados con su puerto asignado.


Anexo I Manuales de usuario. Manual de WebCP2003

116

Capítulo 3 MANUAL DE WEBCP2003

1 Entrar en la aplicación

Ilustración 8: Entrando en WebCP2003

Esta es la primera página de la aplicación. Para evitar complicaciones se ha establecido un usuario ya registrado y su contraseña en la pantalla de inicio. Una vez validados pasaremos a la página principal de la aplicación, la cual está concebida como una especie de escritorio desde el cual podremos acceder a las distintas opciones de manejo de la red Modbus, controlada por RemModbus, así como a los detalles de cada dispositivo CP200X



117

2 Sistema inteligente de interacción

El manejo de la aplicación Web esta fundamentado en un sistema inteligente desarrollado exclusivamente para evaluar el estado en el que se encuentra la red, y ofrecer las diferentes opciones disponibles o más lógicas para cada situación concreta. Esto se ha llevado a cabo mostrando mensajes emergentes en la pantalla principal antes mencionada, que informan de la situación actual y las posibilidades de interacción en ese marco. El manejo es muy intuitivo y fácil de comprender. A continuación se muestra un ejemplo del funcionamiento con dichos mensajes.

Ilustración 9: Sistema inteligente de interacción

Vemos en la ilustración como el sistema ha detectado una situación potencial de información obsoleta, y vemos también como ofrece dos soluciones posibles. Por otra parte, se muestra que el servidor aun no tiene actualizada la lista del polling que se ha confeccionado, y presenta la forma de hacerlo. En el último aviso vemos como se detecta que el usuario tiene un nivel adecuado para administrar los usuarios.



118

3 Interacción simple

Hemos visto que el sistema se adapta automáticamente a la situación de la red y ofrece los medios necesarios para efectuar los cambios pertinentes. Sin embargo, siempre habrá situaciones en las que el usuario crea que debe ejecutar una acción o un proceso, independientemente del estado de la red, bien porque tenga información privilegiada de la red, o bien porque lo vea oportuno. Es por eso que se ha facilitado un menú desplegable, que permite llevar a cabo estas acciones de forma unilateral, independientemente del sistema inteligente. Para ello pulse en el botón Herramientas, que abrirá un pequeño menú, que permite interactuar como se ha mencionado.

Ilustración 10: Menú Herramientas

Al accionar este menú, se desactivarán automáticamente los mensajes del sistema inteligente, relacionados con él. La utilización de este menú está restringida a los usuarios de más alto nivel, por razones de seguridad.



119

4 Administración del polling y obtención de medidas

El polling se define individualmente para cada dispositivo CP2003 conectado a la red. Para ello podremos acceder desde la pantalla principal a cada uno de los dispositivos conectados y establecer que medidas se quieren tomar. Una vez hayamos terminado de seleccionar las medidas que queremos tomar sobre el dispositivo, el sistema habrá detectado que ha habido algún cambio en el polling y ofrecerá la posibilidad de guardar los cambios o por contrario, volver al estado inicial del servidor.

Ilustración 11: Modificando el polling

En el ejemplo de arriba estamos añadiendo la medida VST sobre el dispositivo 0xA5. En general, si decidimos guardar el polling, nos devolverá a la pantalla principal, desde la que podremos acceder de nuevo a otro dispositivo sobre el que queramos tomar medidas, en caso de necesitar observar mediciones de más de un dispositivo.



120

De esta forma vamos a ir definiendo el polling. Cuando hayamos terminado de concretar las medidas que queremos incluir en el polling nos encontraremos en la página principal con el siguiente aviso en forma de mensaje.

Ilustración 12: Modificando el polling II

Pulsamos en Actualizar, y el servidor RemModbus, cambiará su lista de polling. Por último, es posible que sea necesario arrancar el proceso en el servidor, dependiendo de si estuviera previamente funcionando o no. Para cualquiera de los casos se mostrará un mensaje del estilo del aviso de la siguiente ilustración.

Ilustración 13: Start/stop polling



121

5 Administración de usuarios

Al sistema de administración de usuarios sólo podrán acceder los usuarios de nivel más alto. Para ello se dispondrá de un acceso por medio de mensaje típico de la aplicación, y de otro por medio del desplegable Herramientas. Este apartado nos permitirá tanto ver los usuarios del sistema como realizar modificaciones.

5.1 Editar 5.1 Editar usuario.

Para editar el nivel de acceso de un usuario, será necesario activar el modo edición en la página de administración de usuarios, con el botón “Selección de niveles de usuario”

Ilustración 14: Cambiando nivel de usuario



122

Esta acción nos devolverá a la misma página anterior, pero preparada para editar. Seleccionamos el usuario que queremos modificar, y pulsamos en “Cambiar Nivel”. En el ejemplo vemos como hemos cambiado el nivel del usuario Michael Scofield a Owner.

Ilustración 15: Modificando usuarios

5.2 Borrar usuario

El método a seguir para eliminar un usuario, es el mismo que para editarlo: en caso de ser necesario activar el modo borrar, seleccionar el usuario a borrar y pulsar en “Borrar Usuario”.



123

5.3 Añadir usuario

Los usuarios se añaden por medio del menú desplegable “Añadir Usuarios” de la página de administración de usuarios, que se mantendrá desplegado hasta que terminemos de añadir usuarios y volvamos a plegarlo.

Ilustración 16: Añadiendo usuarios

Se introducen los parámetros requeridos y se añade pulsando el botón.

Ilustración 17: Usuario añadido


Anexo I Manuales de usuario. Manual de RemCP2003

124

Capítulo 4 MANUAL DE REMCP2003

Ilustración 18: Conexión a RemModbus

Lo primero que se muestra en la aplicación es la ventana de conexión a RemModbus. Introducimos usuario, contraseña y la dirección en la que reside la aplicación, y pulsamos sobre el botón de conexión. La aplicación ofrece dos modos de actuación según en que pestaña nos encontremos. La pestaña inicial nos permite conocer la situación actual de un determinado valor.

Ilustración 19: RemCP2003. Toma de medidas


Anexo I Manuales de usuario. Manual de RemCP2003

125

En la ilustración de la página anterior hemos tomado la medida de voltaje VFR sobre el dispositivo con dirección 0x03 y hemos obtenido un resultado de 222 V.

Ilustración 20: RemCP2003. Avanzado

La segunda pestaña nos permite actuar como administrador de cualquier red Modbus introduciendo una trama arbitraria en la red. Para crear la trama se añade Byte a Byte en hexadecimal. No se ofrece cálculo de CRC pero si RemModbus detecta que no tiene CRC, lo añadirá él mismo. Vemos como se ha enviado la trama aleatoria 0x330x33-0x33-0x33-0x33-0x33- la cual lógicamente no ha obtenido respuesta como se refleja abajo.

Recordemos que RemCP2003 sólo funciona con la modalidad DAT_ABS de RemModbus por lo que si el servidor está ocupado, la aplicación quedará esperando a que termine el servidor, para recibir una respuesta a la petición que se haga.


126

Anexo I Manuales de usuario. Manual de RemBridge

Capítulo 5 MANUAL DE REMBRIDGE El funcionamiento es muy sencillo ya que tan solo consiste en conectarse a RemModbus con una ventana de conexión [Ilustración

18: Conexión a

RemModbus] y posteriormente en conectarse a un puerto COM del ordenador en el que reside la aplicación [Ilustración 4: Configuración de la

conexión Modbus], a

través del cual capturaremos el tráfico y lo enviaremos al servidor, que tratará las tramas como cualquier otro programa RemModbus.

Ilustración 21: RemBridge

Permaneceremos conectados hasta que cerremos el la ventana anterior. Es importante que se haya creado un puente entre dos puertos virtuales. En el caso anterior debe de existir otro puerto virtual conectado a COM4, al que se conectaran las aplicaciones típicas Modbus.


Modbus Java

Recommend Documents

servidor se esta actualizando