implantaciÓn de modbus tcp en system on chip (soc) …

IMPLANTACIÓN DE MODBUS TCP EN SYSTEMON CHIP (SoC)

Víctor González Fernández

Trabajo de Fin de GradoEscuela de Ingeniería de Telecomunicación

Grado en Ingeniería de Tecnologías de Telecomunicación

TutoresJesús Doval Gandoy

Francisco Poza González

2018

Escola de Enxeñaría de Telecomunicación

Grao en Enxeñaría de Tecnoloxías de Telecomunicación

Mención: Sistemas Electrónicos

Implantación de modbus TCP en System on Chip (SOC)

Autor: Víctor González Fernández

Titores: Jesús Doval Gandoy, Francisco Poza González

Curso: 2017/18

IMPLANTACIÓN DE MODBUS TCP EN SYSTEM ON CHIP (SOC)

1

Indice

Lista de figuras .............................................................................................................................. 2

Lista de tablas ............................................................................................................................... 2

1. Introducción .......................................................................................................................... 3

2. Objetivos ............................................................................................................................... 4

3. Flujo de trabajo ..................................................................................................................... 4

4. Hardware .............................................................................................................................. 5

4.1. PLC (Programmable Logic Controller) .......................................................................... 6

4.2. Nexys 4 .......................................................................................................................... 7

5. Software ................................................................................................................................ 7

5.1. Vivado Design Suite 2015.4 .......................................................................................... 7

5.2. Xilinx SDK 2015.3 .......................................................................................................... 9

5.2.1. Servidor modbus TCP............................................................................................ 9

5.2.2. Cliente modbus TCP ............................................................................................ 10

5.2.3. LabView ............................................................................................................... 11

5.3. Wireshark .................................................................................................................... 11

6. Resultados ........................................................................................................................... 11

7. Conocimientos adquiridos .................................................................................................. 12

8. Conclusiones ....................................................................................................................... 13

9. Bibliografía .......................................................................................................................... 14

10. Anexos ............................................................................................................................. 15

Anexo A: Estado del arte ........................................................................................................ 15

Anexo B: Modbus TCP ............................................................................................................ 16

Anexo C: Lightweight IP .......................................................................................................... 25

Anexo D: Funciones modbus .................................................................................................. 33

Anexo E: Software en Microblaze .......................................................................................... 36

Anexo F: Presupuesto del proyecto ....................................................................................... 40


2

Lista de figuras Figura 1. Elementos del sistema.................................................................................................... 5 Figura 2. EPC 3004 de Eurotherm ................................................................................................. 6 Figura 3. Microblaze y periféricos ................................................................................................. 8 Figura 4. Diagrama de flujo aplicación Servidor ............................................................................ 9 Figura 5. Diagrama de flujo aplicación Cliente ............................................................................ 10 Figura 6. Aplicación Cliente Labview ........................................................................................... 12 Figura 7. Ethernet en el modelo OSI ........................................................................................... 16 Figura 8. Modo unicast ................................................................................................................ 19 Figura 9. Modo broadcast ........................................................................................................... 19 Figura 10. Construcción de un paquete modbus ........................................................................ 21 Figura 11. Categorías de códigos de función modbus ................................................................ 24 Figura 12. PBUF_RAM con datos en memoria gestionados por el subsistema pbuf .................. 27 Figura 13. PBUF_RAM encadenado con un PBUF_ROM que tiene datos en una memoria externa ........................................................................................................................................ 28 Figura 14. PBUF_POOL encadenado ........................................................................................... 28 Figura 15. Estructura de una interfaz de red .............................................................................. 29 Figura 16. Programa principal ..................................................................................................... 36 Figura 17. Conexión establecida ................................................................................................. 36 Figura 18. Información mostrada en el terminal serie ................................................................ 37 Figura 19. Respuesta que obtiene el cliente ............................................................................... 37 Figura 20. Detalles de la trama de respuesta .............................................................................. 37 Figura 21. Conexión establecida ................................................................................................. 38 Figura 22. Opción escogida en este caso .................................................................................... 38 Figura 23. Trama de petición....................................................................................................... 39 Figura 24. Trama de respuesta .................................................................................................... 39

Lista de tablas Tabla I. Funciones modbus soportadas por el controlador .......................................................... 6 Tabla II. Bloques de modelo de datos modbus ........................................................................... 20 Tabla III. Prefijos de rangos de datos .......................................................................................... 20 Tabla IV. Campos de la cabecera modbus ................................................................................... 22 Tabla V. Códigos de la clase 0...................................................................................................... 22 Tabla VI. Códigos de la clase 1 .................................................................................................... 23 Tabla VII. Códigos de la clase 2 ................................................................................................... 23 Tabla VIII.Códigos de excepción de modbus comunes ............................................................... 23 Tabla IX. Funciones de la RAW API .............................................................................................. 31 Tabla X. Funciones Netconn API .................................................................................................. 32 Tabla XI. Funciones BSD Socket API ............................................................................................ 32 Tabla XII. Coste material ............................................................................................................. 40 Tabla XIII. Coste personal ............................................................................................................ 40 Tabla XIV. Coste total .................................................................................................................. 40


3

1. Introducción

Actualmente, debido a las funcionalidades que presentan, los sistemas embebidos han inundado los campos de la industria, la medicina, las comunicaciones y el ejército.

El término embebido hace referencia al hecho de que la electrónica o el sistema electrónico de control es una parte integral del sistema en que se encuentra. Esto hace que este tipo de sistemas estén sujetos a cumplir ciertos requisitos de tamaño, fiabilidad, consumo y coste. Un ejemplo de este tipo de sistemas son los System on Chip (SoC).

Un SoC es un circuito electrónico integrado que contiene varios componentes electrónicos diseñados para trabajar juntos para lograr un objetivo común. La primera parte del término, System, se refiere a que se trata de un conjunto electrónico complejo, mientras que la otra parte, Chip, significa que todos los componentes de ese sistema están ubicados en un solo circuito integrado. De forma más visual, se puede asimilar a un ordenador reducido para encajar en el tamaño de un chip, un SoC cuenta con procesador, placa base, tarjeta de red e incluso una tarjeta gráfica.

Los dispositivos electrónicos tienen una tendencia a reducir su tamaño, es por esto que los SoC destacan en este campo, ya que, al integrar todos los módulos en un mismo chip, permiten reducir sus dimensiones considerablemente. La disminución de potencia consumida es otro factor importante, característica fundamental en sistemas empotrados portátiles, ya que permitirá alargar la duración de la batería.

En este proyecto se emplea un SoC basado en FPGA, que es un tipo de SoC que proporciona varias ventajas en comparación con otras arquitecturas. Un SoC basado en FPGA integra en un solo chip el procesador, la memoria y la red de conexión con lo que provoca una demanda de potencia del sistema significativamente menor. Típicamente, está formado por un núcleo de procesador de 32 bits y diversas funciones, tales como, memoria, interfaces de bus o soporte de red, seleccionables por el diseñador y que permiten diseñar un sistema íntegramente a medida.

En el campo de las FPGAs, la compañía Xilinx es una de las más fuertes en la fabricación de chips además de poseer un soporte muy bueno para desarrolladores. Debido a sus características, las FPGA son uno de los dispositivos más empleados en la construcción de sistemas embebidos flexibles y de bajo coste.

Para la elaboración del proyecto, se ha empleado el soporte ofrecido por Xilinx para el desarrollo de aplicaciones en las que se emplea Ethernet. Éste se basa en aportar ejemplos de aplicaciones software que emplean el protocolo TCP/IP. La pila de protocolos empleada en los ejemplos está implementada mediante el uso de LwIP (LightweightIP) [Anexo C].

LwIP es un conjunto de bibliotecas y APIs realizadas para permitir el uso de las funciones propias de los protocolos usados en este tipo de comunicaciones. Se centra, sobre todo, en la reducción de los recursos usados a la hora de establecer comunicaciones, pero contando, a su vez, con una comunicación TCP al completo.

Teniendo esto en cuenta, surge la idea de este proyecto, el cual consiste en la realización e implementación de una comunicación P2P empleando el protocolo de comunicación modbus y el protocolo de transporte TCP para el control en tiempo real de autómatas industriales. En él se estudian los protocolos empleados, las opciones de comunicación que ofrece el regulador de temperatura EPC3004 de Eurotherm y su puesta en marcha.

El primer paso del proceso de desarrollo es el diseño de un sistema empotrado que incorpora el microprocesador Microblaze y los periféricos necesarios para la aplicación utilizando el software Vivado 2015.4. A continuación, se desarrolla el programa que ejercerá como cliente y/o servidor


4

y que se implementará en la FPGA. Se desarrolla también una aplicación mediante el software LabView para poder lograr una comunicación con dicha FPGA y así poder validar lo estudiado.

Para concluir este proyecto, se conecta mediante un cable Ethernet la FPGA y el regulador de temperatura con el fin de demostrar su validez.

2. Objetivos

El objetivo principal de este proyecto es proporcionar una solución para la transferencia eficiente de datos entre el procesador y la lógica programable en un SoC basado en Artix, mediante una comunicación punto a punto en la que se emplea el protocolo de aplicación modbus y el protocolo de transporte TCP, para lograr así el control en tiempo real de autómatas industriales.

A continuación, se citan los objetivos individuales a alcanzar en este proyecto:

- Aprendizaje del método de diseño de un System on Chip basado en FPGA. - Comprensión del funcionamiento del protocolo de comunicación modbus TCP. - Implementación de la arquitectura hardware incluyendo los periféricos y las

interconexiones necesarias. - Adaptación al uso de la herramienta Vivado Design Suite de Xilinx. - Desarrollo de una aplicación para la implementación software del protocolo modbus

TCP en una FPGA. - Creación de una aplicación en LabView capaz de controlar la FPGA para hacer

transferencias de datos entre memoria y periféricos. - Demostración práctica en la que se enviarán una serie de datos desde un ordenador

hacia la placa de desarrollo por el puerto Ethernet, empleando la pila de protocolos LwIP.

3. Flujo de trabajo

Una vez definidas las especificaciones del diseño a realizar, el desarrollo se dividirá en dos ramas, como es común en el diseño de sistemas embebidos y SoCs.

Por una parte, se diseñará la arquitectura hardware. En ella se instanciarán el procesador y los periféricos necesarios, se realizarán las interconexiones entre éstos y el procesador y se configurará el sistema de procesamiento y las interfaces necesarias, entre otras cosas. Por otra parte, se diseñará la aplicación software teniendo una base del hardware llamada Board Support Package (BSP), que proporciona los drivers necesarios para gestionar el hardware desde la aplicación. Ambas partes serán integradas para comprobar su correcto funcionamiento en conjunto.

Para finalizar, se diseñará una aplicación en el entorno LabView para simular un autómata industrial y demostrar así la validez del conjunto.

Diseño de la arquitectura hardware del SoC:

El diseño e implementación de este proyecto se basa en un sistema a base de Software/Hardware de uso específico construido dentro de una FPGA utilizando la plataforma Vivado de Xilinx.


5

Configuración de las características de la tarjeta a utilizar, en este caso Nexys 4, y de los periféricos necesarios para realizar la comunicación (puerto Ethernet, UART, LEDs, interruptores).

Teniendo en cuenta los elementos básicos para construir un diseño hardware efectivo, se ha desarrollado una arquitectura básica para este tipo de comunicaciones. Gracias a los ejemplos proporcionados por Xilinx, la arquitectura diseñada optimiza al máximo los recursos proporcionados [6].

Desarrollo del software:

Se utiliza la plataforma Software Development Kit (SDK de Xilinx), con la que se trabaja la lógica que requiere implementarse en el proyecto. Para la implementación de una aplicación software capaz de controlar el EPC3004 de Eurotherm y realizar transferencias de datos entre memoria y periféricos empleamos el lenguaje de programación C.

Creación de una aplicación software capaz de simular un PLC industrial que se comunique con la placa de desarrollo a través del protocolo de comunicación modbus TCP, empleando el software LabView de National Instruments [5].

Planteamiento de una demostración práctica con varias alternativas: - Se enviarán datos desde la placa de desarrollo al PC conectado y con el

programa simulado en LabView activo en modo servidor. - Se enviarán datos desde el programa cliente en LabView al regulador de

temperatura EPC3004 de Eurotherm.

Captura de las tramas enviadas a través de la interfaz Ethernet del PC con el software Wireshark.

4. Hardware

El presente proyecto ha sido realizado aprovechando los recursos que nos ofrecía el Departamento de Tecnología Electrónica y el Departamento de Automática de la Escuela de Ingeniería Industrial de la Universidad de Vigo (Figura 1).

Figura 1. Elementos del sistema


6

4.1. PLC (Programmable Logic Controller)

Se trata de una computadora que se emplea en Ingeniería automática para automatizar procesos electromecánicos, tales como el control de la maquinaria de la fábrica en líneas de montaje. Un PLC es un ejemplo de un sistema de tiempo real, donde los resultados de salida deben ser producidos en respuesta a las condiciones de entrada dentro de un tiempo limitado, de lo contrario no producirá el resultado deseado. A diferencia de las computadoras convencionales, el PLC está diseñado para múltiples señales de entrada y de salida, inmunidad al ruido eléctrico, resistencia a la vibración y el impacto y rangos de temperatura ampliados.

En este proyecto hemos trabajado con el modelo EPC3004 de Eurotherm que se muestra en la Figura 2.

Figura 2. EPC 3004 de Eurotherm

Los productos de la serie EPC3000 de Eurotherm son unos reguladores de temperatura a los que se le pueden conectar diferentes tipos de termopares y que pueden emplear una comunicación vía modbus TCP. Estos reguladores ofrecen las prestaciones de medir la temperatura a través de la señal recibida de un sensor, por ejemplo un termopar, o establecer una consigna. El establecimiento de la consigna delimitará unos valores de temperatura permitiendo, por ejemplo, activar o desactivar un relé conectado a una resistencia para controlar la temperatura en un horno. Esta serie de reguladores soporta las siguientes funciones modbus (Tabla I):

Tabla I. Funciones modbus soportadas por el controlador

Código de función

Descripción

0x03 Lectura de un bloque contiguo de registros de salida

0x04 Lectura de un bloque contiguo (hasta 125) de registros de entrada

0x06 Escritura de un registro

0x10 Escritura de múltiples registros

Por un lado, enviando una trama de lectura en el registro 1, el regulador nos devolverá el valor de la temperatura detectada en cada momento. Por otro lado, si lo que enviamos es una trama de escritura, sobre el registro 273 podemos seleccionar modo de consigna manual (valor 0) o automático (valor 1). En el caso de seleccionar el modo manual, en el registro 2 almacenaremos un valor determinado enviando una nueva trama de escritura.


7

4.2. Nexys 4

En las fases iniciales del desarrollo de un sistema, el diseñador debe elegir sobre qué dispositivo final se implementará dicho sistema. Cada una de las opciones tendrá sus ventajas e inconvenientes, por lo que, dependiendo de los requisitos y de las características del sistema a desarrollar, será más conveniente utilizar una opción u otra.

Las ventajas de emplear una FPGA de este estilo son:

- Mejor rendimiento: con esta tecnología se rompe el paradigma de ejecución secuencial. Aprovechando el paralelismo del hardware, se pueden ejecutar tareas independientes de manera simultánea.

- Reducción de coste: su empleo permite disminuir el tiempo y coste necesario para implementar un nuevo sistema o añadir mejoras a uno ya existente, sin necesidad de rediseñar el hardware.

- Mayor fiabilidad: en el diseño del sistema se emplea una menor cantidad de circuitos integrados, con lo que se obtiene una mayor fiabilidad.

La placa Nexys 4 es una plataforma de desarrollo circuitos digitales completa y lista para usar basada en la última FPGA Artix-7 de Xilinx. Cuenta con una alta capacidad, generosas memorias externas y una colección de USB, Ethernet y otros puertos. Tiene también varios periféricos incorporados, tales como un acelerómetro, un sensor de temperatura, un micrófono digital, un amplificador de altavoz y varios dispositivos de entrada/salida (LEDs e interruptores); esto permite que la Nexys 4 sea apta para una amplia gama de diseños sin necesidad de otros componentes.

5. Software

En el desarrollo de este proyecto se han utilizado varias aplicaciones software con el fin de implementar el protocolo de comunicación modbus TCP en una FPGA para lograr así el control de autómatas industriales. Se ha creado también una aplicación en la que la FPGA funciona en modo servidor, en la que se escucha un puerto a la espera de una conexión.

5.1. Vivado Design Suite 2015.4

Vivado Design Suite es un entorno de desarrollo integrado que sustituye a las herramientas de la suite Xilinx ISE, incorporándolas todas en una misma interfaz gráfica. Esto permite una mejora en la productividad de los diseños, ya que el cambio entre las herramientas se realiza de una forma rápida y dentro del mismo programa. Lo que nos permite esta suite es realizar diseños en FPGA y SoCs para las familias de la serie 7 de Xilinx. Además, permite su fácil implementación mediante la interconexión de IP Cores.

Vivado nos proporciona una interfaz gráfica sencilla, muy útil para nuevos usuarios, que permite la creación de diseños complejos de forma visual. Es posible crear arquitecturas de SoC de forma fácil con IP Integrator mediante la configuración e interconexión de los distintos bloques funcionales (IPs) previamente creados, tanto los proporcionados por Xilinx como los diseñados por el usuario. Si se desea conocer más sobre la creación de diseños con IP Integrator consúltese [8].

IP Core

Los IP Cores son el concepto fundamental del diseño de sistemas SoC con arquitecturas reconfigurables. Estos son los que se encargan de proporcionar una lógica de conexión interna de la FPGA, la cual permitirá el funcionamiento de la plataforma de hardware. En su forma ideal,


8

deberían ser totalmente portables, es decir, ser fácilmente integrados en cualquier tecnología de proveedor o metodología de diseño.

Los IP Core más destacados empleados en este proyecto son (Figura 3):

Transmisor/Receptor asíncrono universal (UART Lite): la interfaz UART Lite puede ser conectada al procesador y provee un método de control para la transmisión de datos serie asíncronos. Una de las características de este bloque es que realiza la conversión de paralelo a serie de los caracteres recibidos a través de la interfaz AXI4-Lite y la conversión de serie a paralelo de los caracteres recibidos a través de una interfaz serie. Otra función destacada es que genera una interrupción de flanco ascendente cuando la FIFO de recepción no está vacía o la FIFO de transmisión está vacía.

Periféricos: se han implementado una serie de periféricos en la arquitectura hardware tales como los interruptores y pulsadores como periféricos de entrada o los LEDs como periféricos de salida. Se requiere una mención especial para el periférico de control de acceso al medio Ethernet Lite. Este permite el control de la capa de acceso al medio según el modelo TCP/IP. Está diseñado para incorporar las características especificadas en el estándar IEEE 802.3. La memoria asigna la interfaz de entrada/salida directa a la memoria del puerto de transmisión y recepción de datos. Esta interfaz es independiente de medios (MII) para la conexión a transmisores/receptores físicos (PHY) externos de 10/100 Mbps.

Microblaze: El sistema que se debe embeber es el procesador Microblaze, el cual es un procesador tipo RISC (Reduced Instruction Set Computer) de 32 bits. Está desarrollado por Xilinx para emplear en sus familias de FPGAs Spartan, Artix, Kintex y Virtex. Microblaze tiene una arquitectura Harvard con interfaces de bus separadas para acceso a datos o instrucciones.

Para conseguir embeber el procesador en la FPGA es necesario contar con una herramienta de desarrollo. En este proyecto se ha empleado el software Vivado que incorpora un conjunto de herramientas y módulos IP (Intellectual Property) que permiten diseñar un sistema de procesamiento embebido completo para la implementación en un dispositivo FPGA. Una vez generado el hardware con Vivado, se exporta al SDK (Software Development Kit) para crear la aplicación software que ejecutará el procesador Microblaze.

Este procesador está clasificado como procesador software (soft-processor), en el cual el usuario no tiene acceso a los detalles VHDL del circuito. Aún así, es una herramienta muy potente para desarrollar proyectos relacionados con arquitecturas paralelas, codiseño y control, puesto que permite una comparación inmediata con otras arquitecturas y metodologías de desarrollo.

Figura 3. Microblaze y periféricos


9

5.2. Xilinx SDK 2015.3

El SDK es un kit empleado en la creación de aplicaciones embebidas que se ejecutarán en el microprocesador de la FPGA. El desarrollo de las aplicaciones software de las FPGAs de Xilinx se realizará desde el SDK.

En este proyecto hemos realizado 2 aplicaciones diferentes: en la primera de ellas se ha implementado un servidor modbus que establece una conexión pasiva en la que su función principal es “escuchar” un puerto, en el caso de modbus el puerto 502, para atender a las peticiones que realice un cliente conectado a ese puerto. La otra aplicación se trata de un cliente modbus, que se encarga de abrir una conexión por un puerto para conectarse a un servidor en una dirección IP determinada.

Para la realización de la conexión con los dispositivos se hace uso de unas interfaces de funciones (APIs) proporcionadas por la implementación de la pila de protocolos TCP/IP denominada LwIP, específica para sistemas embebidos. LwIP proporciona 3 tipos de APIs, de las cuales nosotros emplearemos la RAW API (consultar Anexo B Lightweight IP).

5.2.1. Servidor modbus TCP

A continuación, se ilustra (Figura 4) el diagrama de flujo diseñado que atenderá las peticiones del cliente modbus. Esta aplicación simula el funcionamiento de un autómata con entradas (interruptores), salidas (LEDs) y registros internos.

Figura 4. Diagrama de flujo aplicación Servidor


10

A modo de complementar la imagen anterior, vamos a hacer un pequeño resumen del diagrama de flujo: La ejecución de este código se mantendrá en un estado de reposo en el que solamente se está atendiendo a posibles peticiones de conexión por parte del cliente. Una vez establecida una comunicación válida, comenzará la decodificación de la trama recibida. Si el formato de la trama no es válido, se se produce un error. Si la trama es correcta, una vez decodificada y analizada, se procede a comprobar que el código de función recibido sea un código válido en nuestro sistema. De no ser así, de nuevo se produce un error.

A cada código de función le corresponde una trama con una estructura específica y diferente. Una vez comprobado que la estructura de la trama es correcta en función del código de función recibido, se procede a componer la trama de respuesta. Si la estructura no se corresponde con la específica de cada código, se vuelve a producir un error. Cabe destacar que cada error producido lleva asociado un código de error diferente, de esta forma el cliente podrá averiguar de donde procede e intentar solucionarlo. El siguiente paso a realizar es la composición de la trama de respuesta según los datos recibidos en la petición y los datos almacenados en las bobinas1 y registros. Por último, se envía la respuesta al cliente modbus y se vuelve al estado inicial de reposo para atender a las siguientes conexiones.

5.2.2. Cliente modbus TCP

En la Figura 5 podemos observar el diagrama de flujo de la aplicación diseñada que establecerá una conexión con un servidor a través del puerto 502.

Figura 5. Diagrama de flujo aplicación Cliente

Para ayudar a comprender este proceso pasamos a describir de forma breve los pasos realizados: El primer paso a realizar es la creación de una conexión TCP con un servidor modbus

1 Las bobinas en un autómata representan de una forma abstracta la bobina de un relé y, por extensión, cualquier tipo de accionador susceptible de ser activado por medio de una señal eléctrica.


11

TCP situado en una dirección IP predefinida. Seguidamente, por el terminal serie se le indica al cliente que introduzca el código de función que desea, mostrando una lista con los códigos disponibles. En función de este código, se van requiriendo los datos necesarios para rellenar los distintos campos de la trama a enviar. Una vez introducidos los datos, se comprueba que estos tengan un valor correcto en cada campo y se procede a componer la trama y prepararla para su envío. Cuando está todo listo se envía la trama y se espera por la respuesta del servidor. Una vez obtenida la respuesta del servidor se analiza que la trama de respuesta sea válida, de no ser así se finaliza la conexión. Si la trama es válida se procede a procesar los datos recibidos y, una vez realizado este paso se finaliza la comunicación.

5.3. LabView

LabView es un software que proporciona un potente entorno de desarrollo gráfico para el diseño de aplicaciones de ingeniería de adquisición de datos, análisis de medidas y presentación de datos gracias a un lenguaje de programación sin la complejidad de otras herramientas de desarrollo. LabView emplea un modelo de flujo de datos en lugar de líneas secuenciales de código de texto, lo que permite escribir un código funcional utilizando un diseño visual que se asemeja al proceso de pensamiento de un programador. Esto significa que dicho programador emplea menos tiempo preocupándose por el punto y coma y más tiempo resolviendo los problemas realmente relevantes.

5.4. Wireshark

Software analizador de protocolos utilizado para realizar análisis y solucionar problemas en redes de comunicaciones. Tiene un uso extendido en desarrollo de software y protocolos o como herramienta didáctica. Whireshark permite capturar y monitorizar todos los paquetes de red que pasan por una interfaz determinada con el solo hecho de poner nuestra tarjeta de red a escuchar en modo promiscuo.

Tener la información detallada que nos facilita este software nos permite poder analizar el tráfico que pasa por nuestra red y así poder solucionar o incluso prevenir los posibles problemas que nos puedan surgir.

Debido a sus características, ha sido muy útil en el desarrollo de este proyecto, tanto para la depuración de errores como para la demostración del correcto funcionamiento del sistema.

6. Resultados

A continuación, presentamos los resultados obtenidos durante el proceso de realización del presente proyecto, los cuales son ilustrados mediante las imágenes correspondientes:

Diseño de un System on Chip basado en FPGA e implementación de la arquitectura hardware incluyendo los periféricos y las interconexiones necesarias.

Desarrollo de la aplicación para la implementación software del protocolo modbus TCP en una FPGA empleando el software SDK. Se ha desarrollado satisfactoriamente una aplicación servidor, que ejecuta una conexión pasiva, y una aplicación cliente, que realiza una conexión activa [Anexo E].


12

Desarrollo de las aplicaciones cliente y servidor con el software Labview (Figura 6).

Figura 6. Aplicación Cliente Labview

Comunicación entre la aplicación cliente de Labview con la aplicación servidor programada en la FPGA.

Comunicación entre la aplicación cliente de Labview y el regulador de temperatura comercial empleado.

7. Conocimientos adquiridos

Los conocimientos adquiridos en el desarrollo de este trabajo se dividen en tres grupos según las distintas etapas llevadas a cabo: una etapa de aprendizaje y de establecimiento de las bases de desarrollo de un SoC, otra etapa de diseño de la arquitectura hardware y verificación de dicho diseño mediante simulaciones y, por último, el desarrollo de la aplicación software.

Bases de desarrollo de un SoC y aprendizaje:

Protocolo modbus TCP: El primer paso dado en este proyecto ha sido el familiarizarse con el protocolo modbus TCP. Modbus es un protocolo de comunicación de nivel 7 del modelo OSI. El objetivo de modbus es la transmisión de información entre distintos equipos electrónicos conectados a un mismo bus. Dicho bus constará de un solo elemento cliente y uno o varios elementos servidores. Encapsulando las tramas modbus dentro de las tramas de TCP, conseguiremos el protocolo empleado en el proyecto, modbus TCP, con el que conseguiremos una comunicación entre dispositivos de forma fácil e inmediata. El que el protocolo modbus TCP haya extendido su uso hasta ser el protocolo más estandarizado en el sector industrial se debe a varias razones: puede funcionar sobre casi todos los medios de comunicación, es público y tiene una implementación relativamente sencilla, entre otros. Una vez entendido su funcionamiento, el siguiente paso ha sido el estudio de los códigos de función del protocolo, sus formatos de petición y respuesta. En este proyecto hemos implementado los códigos de función básicos de un elemento modbus, leer múltiples registros (0x03) y escribir a múltiples registros (0x16), añadiendo a ellos algunas


13

funciones de acceso a todos los tipos de datos (0x01, 0x04) y otras de transferencia de datos, necesarias para operaciones de rutina (0x0F). Para información más detallada sobre el protocolo consúltese el Anexo D Funciones modbus.

Método de diseño de un System on Chip basado en FPGA: Se observará una clara distinción entre el diseño hardware y el desarrollo software durante la realización del proyecto.

Adaptación al uso de las herramientas de desarrollo de Xilinx, en este caso Vivado Design Suite y SDK.

8. Conclusiones

En el presente trabajo de fin de grado se ha desarrollado un sistema embebido sobre la tarjeta Nexys 4, capaz de controlar y monitorizar un PLC empleando el protocolo de comunicación modbus sobre TCP/IP.

Durante el desarrollo del proyecto ha sido necesaria una etapa inicial de aprendizaje del manejo de las distintas herramientas utilizadas, ya que algunas de ellas no habían sido empleadas con anterioridad.

A la hora del diseño de la arquitectura del SoC y la aplicación software, ha resultado de gran utilidad el empleo de los manuales y guías de usuario proporcionados por Xilinx. Para la resolución de los diferentes problemas que han ido surgiendo a la hora de implementar la pila de protocolos LwIP, ha sido necesario realizar una depuración de la aplicación software desarrollada y un proceso de investigación en la documentación disponible para encontrar la fuente de error. En este sentido, ha sido de gran ayuda la realización de dos programas en LabView utilizando las funciones modbus disponibles. Con esto hemos conseguido comprobar el funcionamiento y una ayuda en la depuración de las dos aplicaciones desarrolladas en la FPGA: el servidor y el cliente modbus TCP.

Ha sido también de gran ayuda la herramienta de análisis de las tramas circulantes por la interfaz Ethernet, ya que mostraba de una forma muy visual el formato de trama que se estaba enviando en cada caso. Gracias a esto y a un documento en el que se detalla a la perfección la composición de las tramas, ha sido relativamente sencillo lograr la comunicación perfecta entre la FPGA y la aplicación desarrollada en LabView.

El último paso realizado ha sido una prueba de comunicación entre un autómata real y la FPGA, empleando en esta el cliente modbus desarrollado.

A la vista de los resultados y de las conclusiones descritas, se puede concluir que se ha cumplido con el objetivo general de este TFG.


14

9. Bibliografía

[1] Modbus.org <Modbus application protocol specification V1.1b3>

[2]http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf (14/07/2018)

[3] Modbus.org <Object Messaging Specification for the MODBUS/TCP Protocol Version 1.1>

[4] Lwip.pdf (Dunkels, Adam 2001)

[5] http://www.ni.com/tutorial/13911/en/ (14/07/2018)

[6]https://reference.digilentinc.com/learn/programmable-logic/tutorials/nexys-4-getting-started-with-microblaze-servers/start (14/07/2018)

[7] http://bibing.us.es/proyectos/abreproy/90946/fichero/marhertin.pdf (14/07/2018)

[8] www.xilinx.com (14/07/2018)

[9] http://lwip.wikia.com/wiki/Raw/TCP (14/07/2018)

[10] https://radi.org.ar/wp-content/uploads/2016/10/16-3.pdf (14/07/2018)

[11] http://aquiro.weebly.com/modbus.html# (14/07/2018)

[12] https://www.indeed.es/salaries/Ingeniero/a-electr%C3%B3nico/a-Salaries (14/07/2018)

http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf

http://www.ni.com/tutorial/13911/en/

https://reference.digilentinc.com/learn/programmable-logic/tutorials/nexys-4-getting-started-with-microblaze-servers/start

https://reference.digilentinc.com/learn/programmable-logic/tutorials/nexys-4-getting-started-with-microblaze-servers/start

http://bibing.us.es/proyectos/abreproy/90946/fichero/marhertin.pdf

http://www.xilinx.com/

http://lwip.wikia.com/wiki/Raw/TCP

https://radi.org.ar/wp-content/uploads/2016/10/16-3.pdf

http://aquiro.weebly.com/modbus.html

https://www.indeed.es/salaries/Ingeniero/a-electr%C3%B3nico/a-Salaries


15

10. Anexos

Anexo A: Estado del arte Vivimos en la época de la cuarta revolución industrial. De ahí surge el término Industria 4.0. Esta revolución industrial está impulsada por la transformación digital basada en la incorporación de nuevas tecnologías y está íntimamente ligada a la relación entre la automatización y las tecnologías de la información y comunicación. Esta relación es la base de nuestro proyecto.

Automatización: Los principales elementos empleados en la automatización industrial son los PLCs. Los PLCs (Programmable Logic Controller), también conocidos como autómatas industriales, aparecieron con el propósito de eliminar el enorme costo que significaba el mantenimiento de un sistema de control electromecánico (basado en relés) a finales de los años 60. Se trata de equipos electrónicos capaces de ejecutar un programa cíclicamente y que permiten controlar automáticamente cualquier proceso o desarrollo industrial. Cualquier elemento de tipo PLC debe contar como mínimo con una CPU y una interfaz de entrada/salida. Esta interfaz está conectada a dispositivos de campo, tales como sensores de los que se leerán datos o actuadores sobre los que se aplicará una acción determinada.

Tecnologías de la información y comunicación: El protocolo de comunicación que hemos empleado en este proyecto es el protocolo modbus. La historia de modbus va ligada a la historia de los PLCs. La empresa Bedford Associates propuso a General Motors un sistema que permitía realizar cambios en las maniobras de un equipo de control sin necesidad de modificar el cableado, al cual se le denominó Modular Digital Controller (Modicon). Esta posibilidad de comunicar equipos apareció en el año 1973 y el primer sistema que lo hizo factible fue modbus [11].

Sin embargo, los sistemas cerrados siempre han presentado muchas dificultades, es por esto que, en 1979, Modicon lo publicó de forma abierta y estandarizó el protocolo. En seguida ganó seguidores en el sector industrial del momento debido a que su código era totalmente abierto, era fácil y rápido de implementar y permitía el intercambio sencillo de información entre equipos.

Modbus define una estructura de mensaje independiente del tipo de red por el que se comuniquen, de esta forma se puede emplear en redes basadas en RS-232, RS-485, Ethernet y otras, para posibilitar la comunicación entre dispositivos. También es muy eficiente en aplicaciones de control industrial. Es por los motivos anteriormente nombrados que este protocolo es ampliamente usado en redes de comunicación industrial para los sistemas de automatización y control.

En su versión original estaba orientado a la comunicación a través de un puerto serie, pero la evolución de las comunicaciones en general y en el entorno industrial en particular, ha provocado que su versión modbus TCP sea la más empleada actualmente.

Modbus cuenta con 2 elementos diferentes existentes en su red: el cliente y el servidor. La diferencia radica en que los clientes realizan una conexión activa (abren una conexión, envían una petición al servidor, recogen los datos y cierran la conexión), mientras que los servidores realizan una conexión pasiva (“escuchan” un puerto a la espera de una conexión válida por parte de un cliente). Algunas aplicaciones típicas de un cliente modbus son: leer datos desde sensores remotos (tensión, temperatura, corriente, etc.), controlar procesos remotos (activar relés y válvulas, escribir registros, etc.) o transferir datos (a computadoras, a otros PLC, etc.).

Según menciona Carlos Gerardo Said “Los analistas de la industria mencionan la existencia de más de siete millones de nodos modbus, tan solo en EEUU y Europa” [10]. Motivo más que suficiente como para despertar el interés en desarrollar elementos basados en este protocolo.


16

Anexo B: Modbus TCP

1. Introducción

Existe hoy en día una gran diversidad de sensores y actuadores en los entornos industriales. Del mismo modo, se han creado y optimizado diferentes protocolos para su control, como ejemplo de esto, Fieldbus Foundation, Profibus y Hart están diseñados para instrumentación de control de procesos; mientras que DeviceNet y SDC se emplean en los dispositivos discretos (on-off), donde el tiempo de respuesta es un factor crítico. Es por este motivo que en el área de comunicaciones en entornos industriales la estandarización de protocolos es un tema en permanente discusión. En búsqueda de una estandarización, los múltiples buses de campo han ido perdiendo terreno a favor de otras tecnologías de comunicación emergentes. Este es el caso de Ethernet.

Ethernet es un estándar de redes de computadoras de área local con acceso al medio por detección de la onda portadora y con detección de colisiones. Este estándar se tomó como base en la redacción del estándar internacional IEEE 802.3 y, usualmente, se toman como sinónimos. Este estándar define las características de cableado y señalización de nivel físico y los formatos de tramas de datos del nivel de enlace de datos del modelo OSI (Figura 7).

Figura 7. Ethernet en el modelo OSI

En aplicaciones industriales es usado en conjunto con la pila de protocolos de transporte TCP/IP, que son los empleados en Internet, suministrando un mecanismo de transporte de datos fiable entre máquinas y permitiendo interoperabilidad entre diversas plataformas. Las comunicaciones de este tipo ya no se rigen por el modelo cliente - servidor, sino que en este tipo de redes todos los PLCs pueden leer y escribir entre sí.

2. Comunicaciones PLC vía modbus

Modbus es un protocolo de comunicación de nivel 7 del modelo OSI. Desarrollado y publicado por Modicon en 1979, en su origen estaba orientado al mundo de los controladores lógicos programables o PLCs de Modicon. Se trata de un protocolo de comunicación industrial que fácilmente se puede encontrar en fábricas y edificios inteligentes. En el año 2004 fue liberado y hoy en día la Modbus Organization da soporte y promueve su uso.


17

Debido a esto, el protocolo modbus es el protocolo de comunicaciones más común empleado en entornos industriales, sistemas de telecontrol y monitorización. Lo que implica que, tanto a nivel local como a su nivel de red, en su versión TCP/IP, seguirá siendo uno de los protocolos de referencia en las redes de sensores, telecontrol y un largo etc. de sistemas de información que ya empiezan a asomar la cabeza en nuestro día a día.

3. Modbus sobre Ethernet

Modbus en su origen estaba orientado a una conectividad de líneas serie, como pueden ser RS-232 o RS-485, pero, a medida que las comunicaciones han ido evolucionando, han aparecido variantes como modbus TCP, que permite el encapsulamiento de modbus serie en tramas Ethernet TCP/IP de forma sencilla. Esto es posible debido a que modbus se ubica en el nivel 7 del modelo OSI (capa de aplicación).

Modbus TCP es simplemente el protocolo modbus RTU con una interfaz TCP que se ejecuta en Ethernet. Esto permite a los dispositivos modbus TCP conectarse de modo inmediato y fácil y comunicarse a través de redes Ethernet y fibra óptica.

En resumen, modbus TCP combina una red física (Ethernet) con una creación de redes estándar (TCP/IP) de transporte y un método estándar de representación de datos (modbus) como protocolo de aplicación. Los comandos modbus y los datos del usuario se encapsulan en el mismo campo de la trama TCP/IP sin ser modificados. Sin embargo, existen algunos cambios con respecto a la estructura de la trama modbus serie: no se utiliza el CRC de modbus (checksum) ni el campo de dirección de trama modbus, que es suplantado por el identificador de la unidad en modbus TCP/IP.

La trama Ethernet encapsula la de modbus, pero se rige por la norma IEEE que indica cómo deben comportarse las comunicaciones. El hecho de encapsular la trama modbus es para poder utilizar los códigos de funciones modbus, pero con las ventajas que ofrecen las comunicaciones a través del protocolo Ethernet.

El hecho de que se haya extendido su uso hasta convertirse en el protocolo más estandarizado en el sector industrial se debe a varias razones diferenciales respecto a otros protocolos:

Su ventaja principal es que puede funcionar sobre prácticamente todos los medios de comunicación. Por ejemplo, por medio de cables de par trenzado, fibra óptica, módems telefónicos, microondas o sin cable.

El estándar modbus es público. Esto permite a los fabricantes desarrollar dispositivos sin gastos aplicados al protocolo.

Su implementación es relativamente sencilla y, en consecuencia, el tiempo de desarrollo necesario se acorta considerablemente con respecto a otros protocolos.

La transmisión de información no está comprometida a ningún tipo de datos. Esto implica cierta flexibilidad a la hora del intercambio de información.

3.1. Por qué combinar modbus con Ethernet

Como muchos dispositivos ya son compatibles con Ethernet, ha aumentado su uso en aplicaciones industriales. Al igual que con Ethernet, modbus está libremente disponible, accesible a cualquier persona y ampliamente soportado por muchos fabricantes de equipos industriales. Con tanto en común, la unión del protocolo de aplicación modbus y Ethernet constituye un poderoso estándar de comunicación industrial: modbus TCP. Por si esto fuera poco, debido a que comparten las mismas características físicas y de capa de enlace, sigue siendo totalmente compatible con la infraestructura Ethernet instalada de cables, conectores, interfaz de red de tarjetas, conmutadores y concentradores.


18

Modbus TCP permite el uso de múltiples clientes y velocidades en el rango de Gbps. Además, el número de servidores soportado está asociado al número que pueda manejar la capa física, a menudo entorno a los 1024. Todas las peticiones son enviadas vía TCP, por defecto sobre el puerto 502 [7].

3.2. Descripción

Modbus TCP es un protocolo de comunicación situado en el nivel 7 del modelo OSI y que está basado en la arquitectura cliente – servidor. Fue diseñado para permitir a los equipos industriales, tales como Controladores Lógicos Programables (PLCs), ordenadores, sensores, actuadores y otros tipos de dispositivos físicos de entrada/salida; comunicarse sobre una red.

Modbus es un protocolo de comunicación “sin estado”, es decir, cada solicitud del cliente es tratada independientemente por el servidor y es considerada una nueva solicitud no relacionada con las anteriores, de esta forma, se logra una alta resistencia a rupturas de transacciones debido a ruido. Además, requiere una mínima información de recuperación para mantener la transacción en cualquiera de los dos terminales.

Con modbus TCP una conexión es inicialmente establecida en la capa de aplicación y esa conexión única puede llevar múltiples transacciones independientes, al contrario de lo que sucede en el resto de variantes de modbus.

Es interesante analizar el porqué del empleo del protocolo de transporte TCP en lugar de UDP. La principal razón es ofrecer una conexión fiable: UDP no tiene las herramientas necesarias para verificar que una comunicación haya sido realizada con éxito, mientras que TCP sí que lo verifica.

Otro factor importante es la forma en qué trabajan cada uno de los protocolos. TCP se establece en una conexión en 3 fases. En la primera de ellas, el cliente envía un paquete con una bandera SYN y el número de secuencia inicial. Seguidamente, el servidor reserva recursos y responde con SYN + ACK y su número de secuencia inicial. Por último, el cliente envía un ACK de vuelta. Una vez se establece la conexión, puede comenzar la transferencia y, al finalizar esta, se termina la comunicación cerrando la conexión de un modo similar al de la apertura. Sin embargo, UDP emplea un modelo sencillo de transmisión sin el establecimiento de una conexión que garantice fiabilidad, orden o integridad de los datos. En una comunicación que emplea UDP como protocolo de comunicación, los datos pueden llegar fuera de orden, duplicados o incompletos, es por esto que se debe realizar la corrección y verificación de errores mediante una aplicación activa.

3.3. Funcionamiento y elementos

Su funcionamiento tiene una base muy sencilla: el cliente pregunta y los servidores responden o actúan en función de lo que éste diga. Un dispositivo conectado al bus ejerce de cliente solicitando información del resto de dispositivos conectados que ejercen como servidores y son quienes suministran la información al primero. Según el estándar modbus, en una red modbus habrá un único cliente y hasta un máximo de 247 servidores.

Las peticiones enviadas a los servidores pueden ser de dos modos diferentes:


19

Modo unicast: el cliente se dirige a un servidor individual. Después de recibir y procesar la petición, éste devuelve una respuesta al cliente (Figura 8).

Figura 8. Modo unicast

Modo broadcast: el cliente puede enviar una petición a todos los servidores, pero los servidores no responden. Este tipo de peticiones solo pueden ser de escritura (Figura 9).

Figura 9. Modo broadcast

Acceso y modelo de datos modbus

Los datos disponibles por medio de modbus son almacenados, en uno de los 4 rangos de dirección o bancos de datos: bobinas (coils), entradas discretas (discrete inputs), registros de retención (holding registers) y registros de entrada (input registers). Estos bancos de datos definen el tipo y los derechos de acceso de los datos contenidos. Los dispositivos servidores tienen acceso directo a estos datos, sin embargo, los clientes deben solicitar el acceso a través de diferentes códigos de función (Tabla II).


20

Tabla II. Bloques de modelo de datos modbus

Bloque de memoria Tipo de datos Acceso cliente Acceso servidor

Bobinas Booleano Lectura/Escritura Lectura/Escritura

Entradas discretas Booleano Solo lectura Lectura/Escritura

Registros de retención Palabra sin signo Lectura/Escritura Lectura/Escritura

Registros de entrada Palabra sin signo Solo lectura Lectura/Escritura

Dirección del modelo de datos

La especificación define que cada bloque contiene un espacio de dirección de un máximo de 65536 elementos y no se requiere que sean implementados los rangos completos permitidos por la especificación.

Para simplificar la definición de ubicaciones del bloque de memoria, se introdujo un esquema de numeración que añade prefijos a la dirección de los datos en cuestión (Tabla III).

Tabla III. Prefijos de rangos de datos

Bloque de datos Prefijo

Bobinas 0

Entradas discretas 1

Registros de entrada 3

Registros de retención 4

De este modo, para referirnos a un elemento como registro de retención 14 en la dirección 13 (el direccionamiento comienza en 0), un manual se referirá a un elemento de datos en la dirección 400,014 si se utiliza todo el espacio de dirección del dispositivo (los 65536 registros).

Codificación de los datos

Modbus emplea una representación ‘big-endian’ para direcciones y datos. Esto significa que cuando se transmite una cantidad mayor que 1 Byte, el primer Byte en enviarse es el más significativo. Veámoslo en un ejemplo:

Datos a enviar (formato hexadecimal): 0xABCD

Primer envío: 0xAB

Segundo envío: 0xCD

Transmisión de los datos

Inicialmente se establece una conexión en el nivel de aplicación que puede llevar múltiples transacciones independientes.

TPC permite establecer un gran número de conexiones concurrentes, de esta manera el cliente puede reutilizar una conexión previamente establecida en el momento de realizar una transacción de datos.

Admite las configuraciones P2P y Cliente/Servidor. En ambos casos los mensajes de objeto se comunican en serie en la parte de datos del protocolo.

El mensaje modbus está identificado por un código de función que precede a los datos.

Cada petición de mensajería de objeto debe ser designada con un código de acción par y la respuesta con un código impar.


21

Acceso a la red

El protocolo de acceso al medio es CSMA-CD (acceso múltiple con detección de portadora-detección de colisiones).

3.4. Ventajas del protocolo modbus TCP

Escalable en complejidad. Un dispositivo que solo tiene un propósito simple solamente necesita implementar uno o dos tipos de mensaje.

No se requiere usar herramientas de configuración complejas cuando se añade una nueva estación a una red modbus TCP.

No es necesario equipo o software propietario de ningún vendedor, cualquier sistema con una pila de protocolos TCP/IP puede emplear este protocolo.

Se pueden lograr altas tasas de transmisión sobre una única estación.

La red puede ser configurada para lograr tiempos de respuesta garantizados en el rango de milisegundos.

3.5. Estructura del protocolo

Figura 10. Construcción de un paquete modbus

Como se observa en la Figura 10, los campos de código de función y de datos de la trama del protocolo modbus son absorbidos en su forma original [3]. Por lo tanto, una unidad de datos de aplicación (ADU) toma la forma de un identificador de cabecera de 7 Bytes y que pasará a conformar la nueva cabecera. La unidad de datos de aplicación modbus TCP/IP completa se incrusta en el campo de datos de una trama TCP estándar y se envía a través de TCP. Podemos observar que el funcionamiento de modbus a través de Ethernet es casi transparente a la estructura del registro modbus.

En la Tabla IV se describen los diferentes campos que conforman la cabecera o prefijo (MBAP – Modbus Application Protocol) [2]:


22

Tabla IV. Campos de la cabecera modbus

Campos Longitud Descripción Cliente Servidor

Identificador de Transacción

2 Bytes Identificación de una transacción de petición / respuesta modbus

Inicializado por el cliente

Copiado por el servidor desde la petición recibida

Identificador de Protocolo

2 Bytes 0 = Protocolo modbus Inicializado por el cliente


Longitud 2 Bytes Número de Bytes que le siguen

Inicializado por el cliente (petición)

Inicializado por el servidor (respuesta)

Identificador de unidad

1 Byte

Identificación del servidor remoto conectado en una línea serie o en otros buses

Inicializado por el cliente


Identificador de transacción: Este campo se emplea para que un cliente modbus TCP pueda establecer simultáneamente múltiples conexiones con diferentes servidores y pueda identificar cada una de las transacciones. Este número no tiene valor para el servidor, pero son copiados literalmente desde la solicitud a la respuesta del cliente.

Identificador de protocolo: El protocolo modbus está identificado con el valor 0.

Longitud: Especifica el número de Bytes que siguen incluyendo el identificador de unidad. La longitud es una cantidad de 2 Bytes, pero el Byte más significativo se establece a cero, ya que los mensajes son más pequeños que 256.

Identificador de unidad: Típicamente es empleado para comunicar un servidor modbus a través de una pasarela o Gateway entre una red Ethernet TCP-IP y una línea serie de modbus.

3.6. Clases

En modbus se diferencian 3 clases de funciones. De esta forma tenemos las funciones de Clase 0 (Tabla V) que generalmente son considerados el mínimo para un dispositivo modbus útil, ya que dan a un cliente la habilidad de leer o escribir en el modelo de datos.

Tabla V. Códigos de la clase 0

Código Función

03 Leer múltiples registros

16 Escribir a múltiples registros

La Clase 1 está formada por el conjunto de funciones necesarias para tener acceso a todos los tipos del modelo de datos. En la Tabla VI podemos observar todas las funciones pertenecientes a esta clase.


23

Tabla VI. Códigos de la clase 1

Código Función

01 Leer estado de salidas discretas

02 Leer estado de entradas discretas

04 Leer registros de entrada

05 Forzar una salida discreta

06 Prefijar un registro holding único

07 Leer estados de excepción

Las funciones de Clase 2 son las dedicadas a transferencia de datos necesarias para operaciones de rutina, tales como supervisión y HMI (Tabla VII). Se trata de funciones más especializadas que son implementadas con menos frecuencia.

Tabla VII. Códigos de la clase 2

Código Función

15 Fijar múltiples salidas

20 Leer referencia general

21 Escribir referencia general

22 Enmascarar registro de escritura

23 Leer / escribir registros

24 Leer FIFO

Por último, tenemos los comandos específicos de cada máquina, red o vendedor. Estas funciones no son apropiadas para propósitos de interoperabilidad porque todas ellas son dependientes de cada máquina.

3.7. Excepciones

Como en todos los sistemas, pueden ocurrir errores en el envío/recepción de las tramas. Estos errores pueden ser desde una solicitud con un formato inadecuado hasta entradas incorrectas. Cuando ocurre un error, los servidores utilizan excepciones para indicar las condiciones del mismo. Las excepciones son reportadas al cliente modbus con un formato definido y en función del código del error. En el campo código de función se añade 0x80 al valor del código de función modbus enviado y, en lugar de enviar los datos normales asociados a ese código de función modbus, las respuestas incluyen un solo código de excepción (Tabla VIII).

Tabla VIII. Códigos de excepción de modbus comunes

Código de excepción Descripción

0x01 El código de función recibido no está soportado

0x02 La solicitud intentó acceder a una dirección no válida

0x03 La solicitud tenía datos incorrectos. La trama estaba mal construida

0x04 Error irrecuperable al intentar procesar la solicitud. La solicitud era válida pero el servidor no podía ejecutarla


24

3.8. Categorías

Hay 3 categorías en las que se encuadran los códigos de función modbus. De esta forma tenemos los códigos de función públicos, los definidos por el usuario y los reservados. En la Figura 11 se puede observar a qué categoría pertenece cada uno. A continuación, detallaremos cada categoría.

CÓDIGOS DE FUNCIÓN PÚBLICOS

Son códigos de función bien definidos.

Únicos.

Validados por la comunidad MODBUS.org.

Públicamente documentados.

Tienen disponible prueba de conformidad.

Incluye tanto códigos de función públicos asignados, como códigos de función no asignados reservados para su uso futuro.

CÓDIGOS DE FUNCIÓN DEFINIDOS POR EL USUARIO

El usuario puede seleccionar e implementar un código de función que no está soportado por la especificación.

No hay garantía de que el uso del código de función seleccionado sea único.

Si un usuario quiere la reposición de la funcionalidad como un código de función público, debe iniciar un RFC (Request For Command) para introducir el cambio en la categoría pública y así conseguir un nuevo código de función público asignado.

Modbus Organization expresamente se reserva el derecho de desarrollar el RFC propuesto.

CÓDIGOS DE FUNCIÓN RESERVADOS

Códigos de función utilizados actualmente por algunas compañías para productos heredados y que no están disponibles para uso público.

Figura 11. Categorías de códigos de función modbus


25

Anexo C: Lightweight IP

1. Introducción

La tecnología de Internet ha demostrado ser lo suficientemente flexible como para incorporar los entornos de red cambiantes de las últimas décadas. Aunque originalmente se desarrolló para redes de bajo nivel como ARPANET, hoy en día la tecnología de Internet existe en las redes del mañana.

Dado que a menudo se requiere que los dispositivos sensores sean físicamente pequeños y económicos, una implementación de los protocolos de Internet tendrá que lidiar con recursos informáticos y memoria limitados. Este documento describe el diseño y la implementación de una pequeña pila TCP/IP llamada LwIP que es lo suficientemente pequeña como para ser empleada en los sistemas mínimos.

En un principio, se consideraba que el protocolo TCP/IP no podía ser implementado en los nodos sensores debido a que estos poseían capacidades muy limitadas en memoria y procesamiento. Sin embargo, las primeras implementaciones que demostraron que esto era viable se les atribuyen a Adam Dunkels y al equipo de desarrollo del Swedish Institute of Computer Science, quienes desarrollaron las pilas LwIP y uIP. El objetivo de la implementación LwIP TCP/IP es reducir la RAM usada manteniendo una pila TCP/IP a escala real. Con una exigencia de memoria RAM muy baja y ocupando menos de 40KB de memoria de programa, la pila LwIP es muy adecuada para utilizar en sistemas embebidos. Está formada por varios archivos, todos escritos en lenguaje C, que se pueden adaptar a casi cualquier necesidad, ya que su uso es libre.

En otras palabras, LwIP (Lightweight IP) es una implementación de la pila de protocolos TCP/IP creada especialmente para sistemas empotrados, ya que los recursos necesarios para su uso son muy reducidos, necesitando muy poca memoria y poco código para hacerla funcionar. Esta pila de protocolos está disponible como software libre, y se puede emplear en variedad de plataformas, con la opción de utilizar sistema operativo o no.

Como en muchas otras implementaciones TCP/IP, los protocolos están diseñados en forma de capas, donde cada capa de protocolo resuelve una parte separada del problema de comunicación. Esta estratificación puede servir como una guía para diseñar la implementación de los protocolos, ya que cada protocolo se puede implementar por separado del otro. Sin embargo, la implementación de los protocolos en una forma estrictamente estratificada puede conducir a una situación en la que la sobrecarga de comunicación entre las capas de protocolo degrada el rendimiento general.

El diseño de las capas ha servido como una guía para el diseño de la implementación de LwIP. Cada protocolo es implementado como su propio módulo, con algunas funciones que actúan como puntos de entrada en cada protocolo. Aunque los protocolos son implementados por separado, se realizan algunas violaciones de capa, con el fin de mejorar el rendimiento tanto en términos de velocidad de procesamiento como en el uso de la memoria.

LwIP se compone de varios módulos. Además de los módulos que implementan los protocolos TCP/IP (IP, ICMP, UDP y TCP), se implementan varios módulos de soporte. Estos módulos de soporte constan de la capa de emulación del sistema operativo, el administrador y los subsistemas de gestión de memoria, las funciones de interfaz de red y las funciones para calcular la suma de comprobación de Internet. LwIP también incluye una API abstracta hecha a medida que no necesita ninguna copia de datos.

A continuación, se introducirán las características básicas de LwIP. Para ampliar dicha información consúltese [4].


26

2. Modelo de proceso

El modelo de proceso de una implementación de protocolo describe de qué manera el sistema se ha dividido en diferentes procesos. Un modelo de proceso que se ha utilizado para implementar protocolos de comunicación se basa en permitir que cada protocolo se ejecute como un proceso independiente. Con este modelo, se aplica una estricta estratificación del protocolo, y los puntos de comunicación entre los protocolos deben definirse estrictamente.

Si bien este enfoque tiene sus ventajas, como los protocolos que se pueden agregar en tiempo de ejecución, la comprensión del código y la depuración es generalmente más fácil; también hay desventajas. La estratificación estricta no es siempre la mejor forma de implementar protocolos. Además, y más importante, para cada capa cruzada se debe hacer un cambio de contexto. Para un segmento TCP entrante, esto significaría tres conmutadores de contexto desde el controlador de dispositivo para la interfaz de red, el proceso de IP, el proceso de TCP y, finalmente, el proceso de aplicación. En la mayoría de los sistemas operativos, un cambio de contexto es bastante lento.

Otro enfoque común es dejar que los protocolos de comunicación residan en el núcleo del sistema operativo. En el caso de esta implementación de los protocolos de comunicación, los procesos de aplicación se comunican con los protocolos a través de llamadas al sistema. Los protocolos de comunicación no están estrictamente separados entre sí, pero pueden usar las técnicas de cruzar la estratificación del protocolo.

LwIP utiliza un modelo de proceso en el que todos los protocolos residen en un único proceso y, por lo tanto, están separados del núcleo del sistema operativo. Los programas de aplicación pueden residir en el proceso LwIP o estar en procesos separados. La comunicación entre la pila TCP/IP y los programas de aplicación se realiza mediante llamadas a función para el caso en que el programa de aplicación comparte un proceso con LwIP o por medio de una API más abstracta.

Tener LwIP implementado como un proceso de espacio de usuario en lugar de en el núcleo del sistema operativo tiene sus ventajas y desventajas. La principal ventaja de tener LwIP como un proceso es que se puede portar a diferentes sistemas operativos. Como LwIP está diseñado para ejecutarse en sistemas operativos pequeños que generalmente no admiten el cambio de procesos ni la memoria virtual, el retraso causado por tener que esperar la actividad del disco si parte del proceso LwIP se intercambia o pagina en el disco no será un problema.

3. Gestión de memoria

La gestión de memoria y almacenamiento en un sistema de comunicación debe estar preparado para acomodar buffers de muchos tamaños variables. Además, con el fin de evitar la copia, debería ser posible permitir que el contenido de datos de los buffers resida en la memoria que no es manejada por el subsistema de red, como la memoria ROM. La gestión de los paquetes se realiza en un buffer llamado pbuf que asigna y organiza toda la memoria para el correcto funcionamiento de la pila. Los buffers utilizan la referencia a memoria, en vez de memoria dinámica. También se utiliza la memoria compartida.

Es por ello que, para que esto funcione, tiene que ser posible compartir la referencia a memoria entre los procesos. Los sistemas operativos utilizados en sistemas embebidos para los que se destina LwIP por lo general no aplican ningún tipo de protección de la memoria, por lo que esto no será un problema


27

PBUF (Paquete buffer)

LwIP utiliza varios tipos de buffers para su manejo. Uno de los buffers utilizados es el pbuf (Packet Buffer). Un pbuf es una representación interna de un paquete LwIP y está diseñado para las necesidades especiales de la pila mínima. Su estructura tiene soporte tanto para asignar memoria dinámica como para permitir que los datos del paquete residan en la memoria estática.

Se pueden vincular varios pbufs entre sí en una lista, llamada cadena pbuf, de modo que un paquete pueda abarcar varios. Los pbufs son de tres tipos: PBUF_POOL, PBUF_RAM, PBUF_ROM.

PBUF_POOL: es el más adecuado para recibir paquetes y almacenarlos rápidamente. Son usados principalmente por los controladores de dispositivos de la red ya que la operación de asignar un solo pbuf es rápida y adecuada para su uso en un controlador de interrupciones. Este es el que emplearemos para el desarrollo de este trabajo (Figura 14).

PBUF_RAM: es más lento, puesto que lleva más gestión de memoria y los paquetes no se guardan en espacios contiguos, resultando en una fragmentación de memoria. Es utilizado cuando una aplicación envía datos que son generados dinámicamente. Aplicaciones puntuales hacen uso de este modo (Figura 12).

PBUF_ROM: se emplean cuando una aplicación envía datos que están ubicados en la memoria gestionada por la aplicación. Es posible que estos datos no se modifiquen después de que el pbuf se haya transferido a la pila TCP/IP y, por lo tanto, su uso principal se produce cuando los datos se encuentran en la ROM (Figura 13).

Figura 12. PBUF_RAM con datos en memoria gestionados por el subsistema pbuf


28

Figura 13. PBUF_RAM encadenado con un PBUF_ROM que tiene datos en una memoria externa

Figura 14. PBUF_POOL encadenado

3.1. Campos del pbuf

Next: puntero al siguiente pbuf en caso de cadena.

Payload: puntero al inicio de los datos.

Len: longitud de los datos contenidos.

Tot_len: suma de los campos len y del valor del campo Tot_len del siguiente pbuf.

Flags: indica el tipo de pbuf.

Ref: contiene un contador de referencia

El administrador de memoria que soporta el esquema pbuf es muy simple. Maneja asignaciones y des-asignaciones de regiones contiguas de memoria y puede reducir el tamaño de un bloque de memoria previamente asignado. El administrador de memoria usa una porción dedicada de la memoria total en el sistema.

Esto garantiza que el sistema de red no use toda la memoria disponible y que el funcionamiento de otros programas no se vea afectado si el sistema de red ha utilizado toda su memoria. Internamente, el administrador de memoria realiza un seguimiento de la memoria asignada colocando una pequeña estructura encima de cada bloque de memoria asignado. Esta estructura contiene dos punteros al bloque de asignación siguiente y anterior en la memoria. También tiene un indicador que informa si el bloque de asignación está asignado o no.


29

La memoria se asigna buscando en dicha memoria un bloque de asignación no utilizado que sea lo suficientemente grande para la asignación solicitada. El primer principio de ajuste se usa para que se use el primer bloque que sea lo suficientemente grande. Cuando se desasigna un bloque de asignación, el indicador utilizado se pone a cero. Para evitar la fragmentación, se verifica el indicador utilizado de los bloques de asignación siguiente y anterior. Si alguno de ellos no se usa, los bloques se combinan en un bloque no utilizado más grande.

3.2. Interfaces de red

Las interfaces de red se mantienen en una lista vinculada global, que está vinculada por el siguiente puntero en la estructura. Cada interfaz de red tiene un nombre, almacenado en el campo de nombre. Éste identifica el tipo de controlador de dispositivo utilizado para la interfaz de red y solo se usa cuando un operador humano configura la interfaz en tiempo de ejecución. El nombre lo establece el controlador del dispositivo y debe reflejar el tipo de hardware que representa la interfaz de red. Por ejemplo, una interfaz de red para un controlador Bluetooth podría tener el nombre bt y una interfaz de red para el hardware IEEE 802.11b WLAN podría tener el nombre de wl. Como los nombres no son necesariamente únicos, el campo num se usa para distinguir diferentes interfaces de red del mismo tipo.

Las tres direcciones IP ipaddr, netmask y gw son utilizadas por la capa IP al enviar y recibir paquetes. No es posible configurar una interfaz de red con más de una dirección IP. Más bien, se debería crear una interfaz de red para cada dirección IP. El puntero de entrada apunta a la función a la que debe llamar el controlador de dispositivo cuando se recibe un paquete.

Una interfaz de red está conectada a un controlador de dispositivo a través del puntero de salida. Este puntero apunta a una función en el controlador de dispositivo que transmite un paquete en la red física y la capa IP la llama cuando se va a enviar un paquete. Este campo está rellenado por la función de inicialización del controlador del dispositivo. El tercer argumento para la función de salida, ipaddr, es la dirección IP del host que debe recibir el cuadro de capa de enlace real. No tiene que ser el mismo que la dirección destino del paquete IP. En particular, cuando se envía un paquete IP a un host que no está en la red local, el cuadro de nivel de enlace se enviará a un enrutador en la red. En este caso, la dirección IP dada a la función de salida será la dirección IP del enrutador.

Finalmente, el puntero de estado apunta al estado específico del controlador del dispositivo para la interfaz de red y lo establece el controlador de dispositivo. En la Figura 15 podemos observar de una manera más visual lo comentado anteriormente.

Figura 15. Estructura de una interfaz de red


30

3.3. Interfaz de Programación de Aplicaciones (API)

Para la realización de la conexión con los dispositivos se hace uso de unas APIs proporcionadas por la implementación de LwIP, permitiendo el desarrollo de aplicaciones sobre el disco duro (mediante RAW API) o sobre un sistema operativo (mediante NETCONN API). La API LwIP fue diseñada a partir del conocimiento de la estructura interna de LwIP para lograr una mayor eficacia en el desarrollo de las aplicaciones. La implementación de la API se divide en dos partes debido al modelo de proceso de TCP/IP. Una parte de la API se implementa como una biblioteca enlazada al programa de aplicación y la otra es implementada en el proceso de TCP/IP en cuestión. Las dos partes se comunican mediante la comunicación entre procesos (IPC), que son los mecanismos previstos por la capa de emulación del sistema operativo. La implementación actual emplea los mecanismos de memoria compartida, paso de mensajes y semáforos.

Si bien estos tipos de IPC son compatibles con la capa del sistema operativo, no necesitan ser respaldados directamente por el sistema operativo subyacente. Para los sistemas operativos que no los admiten nativamente, la capa de emulación del sistema operativo se encarga de emularlos.

El principio general de diseño utilizado es permitir que se haga todo el trabajo posible dentro del proceso de aplicación en lugar de en el proceso de TCP/IP. Esto es importante ya que todos los procesos usan el proceso de TCP/IP para su comunicación. Este código se puede compartir entre los procesos, e incluso si las bibliotecas compartidas no son compatibles con el sistema operativo, el código se almacena en la ROM. Los sistemas integrados usualmente llevan cantidades bastante grandes de ROM, mientras que el poder de procesamiento es escaso.

La gestión del buffer se encuentra en la parte de la biblioteca de la implementación de la API. Los buffers se crean, copian y desasignan en el proceso de la aplicación y el proceso de TCP/IP. El tipo de datos de buffer utilizado en la comunicación con el programa de aplicación es una abstracción del tipo de datos pbuf. Los buffers que llevan la memoria referenciada, a diferencia de la memoria asignada, también se pasan usando la memoria compartida. Para que esto funcione, debe ser posible compartir la memoria referenciada entre los procesos. Los sistemas operativos utilizados en los sistemas integrados para los que LwIP está destinado generalmente no implementan ningún tipo de protección de memoria, por lo que esto no será un problema.

Las funciones que manejan las conexiones de red se implementan en la parte de la implementación de API que reside en el proceso de TCP/IP. Las funciones de API en la parte de la API que se ejecuta en el proceso de la aplicación pasarán un mensaje utilizando un protocolo de comunicación simple a la implementación de la API en el proceso de TCP/IP. El mensaje incluye el tipo de operación que debe llevarse a cabo y cualquier argumento para la operación. La operación se lleva a cabo mediante la implementación de la API en el proceso TCP/IP y el valor de retorno se envía al proceso de la solicitud mediante el envío de mensajes.

Raw API: Es la API de bajo nivel y se basa en el empleo de funciones de devolución de

llamadas (callback) para realizar diferentes tareas. Cuando se inicializa la aplicación, el

usuario necesita registrar funciones de callback a diferentes eventos centrales (tales

como TCP_sent, TCP_err, etc.). Las funciones de callback serán llamadas desde la capa

central de LwIP cuando ocurra el evento correspondiente. La Tabla IX proporciona un

resumen de las funciones de esta API.


31

Tabla IX. Funciones de la RAW API

Función de la API Descripción

Establecimiento de la conexión TCP

tcp_new Crea un nuevo PCB TCP (Bloque de Control de Protocolo).

tcp_bind Vincula un PCB TCP a una dirección IP local y un puerto.

tcp_listen Empieza el proceso de escucha en el TCP PCB.

tcp_accept Asigna una función de callback que será llamada cuando llegue una nueva conexión TCP.

tcp_accepted Informa a la pila LwIP de que una conexión TCP entrante ha sido aceptada.

tcp_connect Conecta a un cliente TCP remoto.

Enviando datos TCP

tcp_write Pone en cola los datos para ser enviados.

tcp_sent Asigna una función de callback que se invocará cuando los datos enviados sean reconocidos por el cliente remoto.

tcp_output Fuerza a los datos en cola a ser enviados.

Recibiendo datos TCP

tcp_recv Establece la función de callback que se llamará cuando lleguen los nuevos datos.

tcp_recved Se debe invocar cuando la aplicación ha procesado el paquete de datos entrantes (para la gestión de ventanas TCP).

Sondeo de aplicación

tcp_poll

Asigna funciones de callback que se llamarán periódicamente. Puede ser utilizado por la aplicación para verificar si quedan datos de la aplicación pendientes de enviar o si hay conexiones que deben cerrarse.

Cerrando y abortando conexiones

tcp_close Cierra una conexión TCP con un cliente remoto.

tcp_err Asigna una función de callback para manejar las conexiones anuladas por el LwIP debido a errores (como errores de falta de memoria).

tcp_abort Aborta una conexión TCP.

Esta librería destaca por su rapidez y bajo consumo de memoria a pesar de que su uso no es el más sencillo. Permite el desarrollo de aplicaciones empleando llamadas eventuales. Esta API proporciona también la mejor velocidad de respuesta y tamaño del código, pero añade complejidad al desarrollo de la aplicación [9].

Netconn API: es una API secuencial de alto nivel que tiene un modelo de ejecución basado en el paradigma de bloqueo de lectura-escritura-cierre. Necesita los servicios de sistemas operativos a tiempo real (RTOS) y habilita las operaciones de multi-conexiones. Para funcionar correctamente, esta API debe ejecutarse en un modo de operación de multi-hilos donde hay uno separado para la pila TCP/IP de LwIP y uno o varios hilos para la aplicación. Estas funciones permiten crear una conexión, ya sea del tipo TCP/IP o UDP, que permiten crear conexiones de tipo servidor que esperan a que un cliente se conecte o de tipo cliente para el caso que se desee conectarse a un servidor. Además, permiten realizar la recepción y el envío de datos a través del objeto de conexión creado, así como


32

monitorizar el estado de las conexiones. La Tabla X muestra un resumen de las funciones de la Nectconn API.

Tabla X. Funciones Netconn API

Función API Descripción

netconn_new Crea una nueva conexión.

netconn_delete Elimina una conexión existente.

netconn_bind Vincula una conexión a una dirección IP local y un puerto.

netconn_connect Conecta a una dirección IP remota y un puerto.

netconn_send Envía datos a la IP / puerto remoto actualmente conectado (no se aplica para conexiones TCP).

netconn_recv Recibe datos de un netconn.

netconn_listen Establece una conexión TCP en el modo de escucha.

netconn_accept Acepta una conexión entrante en una conexión TCP que escucha

netconn_write Envía datos en un netconn TCP conectado.

netconn_close Cierra una conexión TCP sin eliminarla.

BSD Socket API: LwIP ofrece la API estándar de Socket BSD. Esta es una API secuencial que se construye internamente en la parte superior de netconn. En la Tabla XI se pueden observar sus principales funciones.

Tabla XI. Funciones BSD Socket API

Función API Descripción

socket Crea un nuevo socket.

bind Vincula un socket con una dirección IP y un puerto.

listen Escucha por conexiones socket.

connect Conecta un socket a una dirección IP y un puerto de un cliente remoto.

accept Acepta una nueva conexión en un socket.

read Lee datos de un socket.

write Escribe datos en un socket.

close Cierra un socket y lo elimina.

Las APIs de nivel alto (Netconn y Socket) no pueden ser empleadas sin sistema operativo, ya que requieren el uso de hilos de ejecución. El envío de datos se realiza a través de una conexión TCP o como datagramas UDP. Para TCP, los datos se envían pasando a la función de salida un puntero a una región de memoria continua. Existen dos tipos de datos que se utilizan dentro de la API LwIP. Estos son: netbuf (abstracción de un buffer) y netconn (abstracción de una conexión de red). Las estructuras netbuf son buffer que se utilizan para enviar y recibir datos. Internamente, un netbuf se asocia con un pbuf. La memoria asignada es la memoria RAM, que está destinada de forma explícita para la retención de datos de la red, mientras que la referencia a memoria podría referirse a ambas RAM o ROM. La referencia a memoria es útil para enviar datos que no son modificados, como las páginas Web estáticas o imágenes. Cada tipo de datos es representado como un puntero a una estructura en lenguaje C. La API proporciona funciones para modificar y extraer los campos necesarios. La pila TCP/IP dividirá los datos en paquetes del tamaño adecuado y los pondrá en cola para su transmisión.

Otra de las estructuras que se utilizan en LwIP es la llamada PCB (Bloque de Control de Protocolo), cuya función es definir los parámetros de la sesión.


33

Anexo D: Funciones modbus

En este anexo se describen algunos de los códigos de función que se han empleado en este proyecto. Para facilitar su entendimiento se añaden algunos ejemplos reales indicando las tramas de petición y de respuesta en cada caso [1].

01 (0x01) Leer estado de salidas discretas

Este código de función es usado para leer desde 1 hasta 2000 estados de bobinas contiguas en un dispositivo remoto. La petición PDU especifica la dirección de inicio y el número de bobinas. En la PDU las bobinas se direccionan comenzando en cero.

Las bobinas en el mensaje de respuesta son empaquetadas como una bobina por bit en el campo de datos. El LSB (bit menos significativo) del primer byte de datos contiene la salida direccionada en la consulta. Si la cantidad de salida devuelta no es un múltiplo de ocho, los bits restantes en el byte de datos final serán rellenados con ceros. El campo contador de bytes especifica la cantidad de bytes de datos completos.

Petición

Código de función 1 Byte 0x01

Dirección de inicio 2 Bytes 0x0000 hasta 0xFFFF

Cantidad de bobinas 2 Bytes 1 hasta 2000 (0x7D0)

Respuesta


Contador de Bytes 1 Byte N

Estado de la bobina n Byte n2

Error

Código de función 1 Byte Código de función + 0x80

Código de excepción 1 Byte 01 o 02 o 03 o 04

A continuación, observamos un ejemplo de lectura desde la salida discreta 20 a la 38:

Petición Respuesta

Nombre del campo Valor (Hex) Nombre del campo Valor (Hex)

Función 01 Función 01

Dirección de inicio (alto) 00 Contador de Bytes 03

Dirección de inicio (bajo) 13 Estado de las salidas 27-20 CD

Cantidad de salidas (alto) 00 Estado de las salidas 35-28 6B

Cantidad de salidas (bajo) 13 Estado de las salidas 38-36 05

2 n = N si Número de salidas/8 = 0. Si el resultado es diferente de 0 → n = N+1


34

3 (0x03) Leer múltiples registros

Este código de función es empleado para leer el contenido de un bloque contiguo de múltiples registros en un dispositivo remoto. En la petición se especifica la dirección del registro de inicio y el número de registros. Los datos en la trama de respuesta son empaquetados como 2 Bytes por cada registro. Para cada registro, el primer Byte contiene el orden alto y el segundo Byte el orden bajo.

Petición



Cantidad de salidas 2 Bytes 0x0001 hasta 0x7D

Respuesta


Contador de Bytes 1 Byte 2 x n

Valor de los registros n x 2 Bytes 0x0001 hasta 0x07B0

Error



06 (0x06) Escribir un registro

Este código de función es empleado para escribir en un solo registro de un dispositivo remoto.

La trama de petición especifica la dirección del registro a ser escrito. La respuesta normal a esta función es un eco de la petición.

Petición


Dirección del registro 2 Bytes 0x0000 hasta 0xFFFF

Valor del registro 2 Bytes 0x0000 hasta 0xFFFF

Respuesta


Dirección del registro 1 Byte 2 x n

Valor del registro n x 2 Bytes 0x0001 hasta 0x07B0

Error



15 (0x0F) Escribir múltiples bobinas

Este código de función es empleado para forzar cada bobina en una secuencia de bobinas para activarse o desactivarse en un dispositivo remoto. La PDU de petición especifica la referencia de la bobina a ser forzada. Las bobinas son direccionadas comenzando en cero. Por lo tanto, la bobina numerada con uno está direccionada en cero.


35

Los estados ON/OFF pedidos son especificados por el contenido del campo de datos de la petición. Un ‘1’ lógico en una posición de bit del campo solicita que la salida correspondiente esté activada.

Petición

Código de función 1 Byte 0x0F


Cantidad de salidas 2 Bytes 0x0001 hasta 0x07B0

Contador de Bytes 1 Byte N

Valor de las salidas N x 1 Byte

Respuesta



Cantidad de bobinas 2 Bytes 0x0001 hasta 0x07B0

Error



Veámoslo en un ejemplo:

Se quiere escribir el siguiente dato: 0x01CD, de nuevo a partir de la dirección 20.

El contenido de los datos de petición son 2 Bytes: CD 01 (Hex) (1100 1101 0000 0001 binario). El primer Byte transmitido direcciona las salidas 20 a 27, con el Byte menos significativo direccionando la salida más baja en este paquete (28). Los bits no empleados en el último Byte de datos deben ser rellenados con ceros.

Bit: 1 1 0 0 1 1 0 1 0 0 0 0 0 0 0 1

Salida: 27 26 25 24 23 22 21 20 35 34 33 32 31 30 29 28

C D 0 1

Petición Respuesta

Nombre del campo Valor (Hex) Nombre del campo Valor (Hex)

Función 0F Función 0F

Dirección de inicio (alto) 00 Dirección de inicio (alto) 00

Dirección de inicio (bajo) 13 Dirección de inicio (bajo) 13

Cantidad de salidas (alto) 00 Cantidad de salidas (alto) 00

Cantidad de salidas (bajo) 0A Cantidad de salidas (bajo) 0A

Contador de Bytes 02

Valor de las salidas (alto) CD

Valor de las salidas (bajo) 01


36

Anexo E: Software en Microblaze

Como se ha mencionado anteriormente, se han implementado dos aplicaciones diferentes en la FPGA. A continuación, procederemos a explicar un poco más en detalle de qué trata cada una de ellas, ilustrando con alguna imagen para que se comprenda de forma más sencilla.

Programa principal

El programa principal es el encargado de asignar a la FPGA los parámetros necesarios para establecer una comunicación: dirección IP, máscara de subred y la puerta de enlace. Una vez establecidos estos parámetros, se espera a que el usuario escoja la aplicación a emplear (cliente o servidor) y, en función de esto, se ejecuta una aplicación u otra. Para visualizar los parámetros y dar entrada a los datos requeridos por el programa principal, hacemos uso del terminal serie del SDK, como se puede observar en la Figura 16.

Figura 16. Programa principal

Aplicación servidor

Para lograr establecer una conexión pasiva se deben seguir una serie de pasos. Independientemente de la API que se esté utilizando, el procedimiento para establecer una conexión de este tipo es el siguiente: crear una conexión nueva, asociar esa conexión a una dirección IP y un puerto, “escuchar” dicho puerto a la espera de una conexión válida y, por último, aceptar esa conexión. Las funciones de la RAW API a emplear para poder realizar esto son (por este orden):

- tcp_new() - tcp_bind() - tcp_listen() - tcp_connect()

La Figura 17 muestra la conexión establecida una vez se ha escogido la opción de iniciar la aplicación servidor.

Figura 17. Conexión establecida

En este punto, la aplicación analiza las tramas de petición recibidas, las decodifica y envía la respuesta oportuna en función del código de función modbus indicado y la información almacenada en las bobinas y registros (Figura 18). Para comprobar el funcionamiento, empleamos los interruptores disponibles en la FPGA como entradas discretas y la función “Read Operation” del programa creado en LabView para mostrar el resultado de la lectura (Figura 19).


37

Figura 18. Información mostrada en el terminal serie

Figura 19. Respuesta que obtiene el cliente

Como se puede observar en las figuras anteriores, la información que se muestra por el terminal serie acerca del número leído en los interruptores de la FPGA coincide con el valor mostrado en la aplicación de LabView, considerando cada LED como un bit en orden creciente hacia la derecha.

Por si esto fuera poco, para demostrar su validez, a continuación, mostramos la trama recogida por el programa Wireshark en el momento en el que se realizó la comunicación (Figura 20).

Figura 20. Detalles de la trama de respuesta


38

Como podemos apreciar en la figura anterior, la aplicación de LabView emite una petición modbus TCP (dir. IP 192.168.1.100) a la que la aplicación implementada en la FPGA responde afirmativamente con la trama correspondiente. En el anterior anexo hemos indicado cómo deben ser las tramas de petición y respuesta para algunos códigos implementados y, en concreto, para éste. En este caso, solamente analizamos la trama de respuesta porque es la que nos interesa, en el siguiente apartado analizaremos también una trama de petición modbus TCP.

Aplicación cliente

El procedimiento para la creación de una conexión de tipo activa es ligeramente diferente al de la conexión pasiva. En este caso, se debe crear una nueva conexión TCP, asociar esa conexión a una dirección IP remota y un puerto por el que conectarse y, finalmente, llamar a la función que conectará con esa dirección IP y ese puerto. En este caso, las funciones a emplear son las siguientes:

- tcp_new() - tcp_bind() - tcp_connect()

Figura 21. Conexión establecida

Una vez realizada la conexión, el terminal serie espera a que el usuario introduzca una serie de datos por teclado (Figura 21). En función de la opción escogida, se irán mostrando diferentes opciones para rellenar los campos necesarios para construir la trama específica de cada una de ellas (Figura 22).

Figura 22. Opción escogida en este caso

Como en el caso anterior, vamos a detallar la trama analizada por el software Wireshark. En primer lugar, analizamos la trama enviada por la FPGA al regulador de temperatura (Figura 23). Como se puede observar, la trama está correctamente formada, con los valores correspondientes en cada campo, de otra forma, el regulador enviaría una trama de error que provocaría la ruptura de la conexión.


39

Figura 23. Trama de petición

En este caso, en el registro 1 del regulador, está almacenado el valor de la temperatura medida por dicho regulador. Si analizamos ahora la trama de respuesta (Figura 24), podemos obtener, tal y como se ha especificado previamente para esta función, el valor del registro 1 que se corresponde con el de la temperatura. En este caso, el regulador devuelve una temperatura errónea debido a que no tiene un sensor fiable conectado, tal como un termopar tipo J o tipo K, pero para el objetivo del proyecto es suficiente.

Figura 24. Trama de respuesta


40

Anexo F: Presupuesto del proyecto En este anexo se realiza un cálculo aproximado del presupuesto necesario para realizar este proyecto. El cálculo se realizará en 3 partes: presupuesto material, presupuesto personal y presupuesto total.

En la Tabla XII se indica el coste del hardware y software empleado:

Tabla XII. Coste material

Concepto Coste unitario Cantidad (uds.) Total

Licencia de software Xilinx 2559,5€ 1 2559,5€

Licencia de software LabView base 399€/año 1 399€

FPGA Nexys 4 DDR 273,47€ 1 273,47€

Regulador EPC3004 1025€ 1 1025€

Total 4256,97€

El coste relacionado con el personal se indica en la Tabla XIII.

Tabla XIII. Coste personal

Concepto Coste unitario Cantidad (uds.) Total

Salario 8,75€/hora 600 5250€

Total 5250€

Para realizar el cálculo del coste personal se ha estimado que un ingeniero experto, trabajando 8 horas al día durante 20 días al mes, sería capaz de realizar este trabajo en un tiempo de 3 meses y medio. En referencia al coste unitario, se ha tomado como referencia un artículo publicado en la Web que realiza una estimación del sueldo de un Ingeniero/a Electrónico/a en España a partir de 204 fuentes obtenidas directamente de empresas, usuarios y empleos [12]. La última actualización de este artículo se ha realizado el día 9/7/2018.

Con todo esto, estamos en disposición de calcular el total del coste del proyecto (Tabla XIV).

Tabla XIV. Coste total

Concepto Total

Coste Material 4256,97€

Coste Personal 5250€

Total 9506,97€

implantaciÓn de modbus tcp en system on chip (soc) …

Documents