Arquitectura Subsistema Campo

carga. Por esto para la comunicación se eligió gRPC, un protocolo de comunicación liviano que se caracteriza por su baja latencia aun teniendo un flujo elevado de datos y mensajes. A su vez gRPC permite la comunicación entre aplicaciones que utilicen distintos lenguajes de programación, por lo que genera una independencia del lenguaje del cliente y del servidor.

8.2.2 Servidor Campo

Este componente se encarga de la realización de las funcionalidades en el campo, toda la lógica para llevar a cabo las acciones se encuentra almacenada en él. El servidor expone dos interfaces, una REST que recibe los request desde elfrontend local y otra para la comunicación gRPC definida en el archivo “.proto”. Por lo que las peticiones pueden llegar desde dos posibles direcciones, a través del frontend del campo o desde el Mapper, el servidor las toma y en base a la directiva realiza una acción que tendrá o no consecuencias en los dispositivos del campo según si es una consulta o una modificación.

El servidor almacena un archivo local de inicialización con información de los equipos que administra, que se define manualmente basado en los datos del subsistema nube. La existencia del archivo permite una de las cualidades principales del subsistema campo que es continuar operativo y prestando servicios de forma local a pesar de perder conexión a internet. Todos los cambios que se realizan desde el servidor campo buscan ser comunicados al servidor remoto para que este mantenga constancia del estado de los equipos en su conjunto. Un error al comunicar un cambio desde el entorno local no es un motivo para que el sistema falle y no realice la acción. Dentro de los requerimientos deseados se encuentra añadir una cola de mensajes en busca de comunicar los eventos al servidor remoto cuando se retome la conexión.

El servidor también está a cargo del envío delheartbeat, metodología utilizada para informar al servidor remoto que se mantiene activa la conexión con el sistema en campo. Fue elegida debido a su fácil implementación. Desde el inicio del servidor de

campo se intentará realizar el envío del heartbeat al subsistema nube de forma periódica para indicar que la conexión se mantiene establecida. Si luego de un cierto período definido en el subsistema remoto no se recibe un heartbeat, se supondrá que se desconectó.

La presión de las bombas también es comunicada de forma constante, no solo al servidor remoto sino también a los clientes que están conectados al frontend de la casilla de bombas o el campo, a través de eventos Server-Sent Events (SSE) que son enviados desde el servidor a quienes estén conectados a él y se suscribieron (más información puede encontrarse en el apéndice E). Estos permitirán a los usuarios mantener una visión actualizada de la presión de trabajo de las bombas y poder detectar irregularidades.

El servidor está almacenado en un dispositivo Raspberry Pi que se comunica por un puerto serie al microcontrolador Atmel para enviar las acciones a realizar. Este tipo de placas no cuentan con una gran cantidad de memoria por lo que se intentó minimizar el almacenamiento de datos.

8.2.3 Arduino (Microcontrolador Atmega2560)

Los microcontroladores Arduino son sistemas de poca capacidad de almacenamiento y procesamiento, es por esto que la lógica se encuentra en la Raspberry Pi y ellos solo acatan sus órdenes. El programa interno del Arduino cuenta con un loop infinito que se ejecuta constantemente mientras esté encendido.

Dentro de la iteración se colocó una lectura de entrada y en el caso de que se reciba información a través del buffer se definirá qué acción llevar a cabo. Para cada tarea se seleccionó un código de operación que diferencia entre la modificación de estado

Código Descripción

101 Obtener estado del elemento

102 Cambiar el estado del elemento entre

prendido y apagado

103 Obtener la lectura de presión de un

sensor

Figura 11 - Códigos de operación para acciones en microcontrolador

El microcontrolador recibe entre dos o tres parámetros por su buffer: el código de operación mencionado anteriormente, la interfaz sobre la que se llevará a cabo la acción (hace referencia al pin al que está conectado el dispositivo a modificar o consultar) y, en caso de ser necesario, el nuevo estado.

Al trabajar con la lectura de presión desde el microcontrolador, es necesario conocer con qué sensor se realizará la lectura ya que no todos lo hacen de la misma manera. En algunos casos se entrega un valor de voltaje que debe ser mapeado a hectopascales y en otros cuentan con librerías que pueden añadirse al código de la placa para leer un valor de presión en la medida solicitada y no tener que realizar ningún cálculo.

8.2.4 Frontend casilla de bombas y campo

Es la aplicación utilizada por los usuarios del campo para poder realizar acciones de consulta de estado, apagado y encendido de válvulas y bombas y detención del programa actual. El cliente web puede ser accedido a través de la red local del campo y no maneja usuarios. Toda la información expuesta en él corresponde a datos del campo de donde se la esté consultando y no se puede acceder a una visión de otro externo. Las consideraciones de seguridad para este caso son expuestas en el apartado Seguridad.

Este frontend no tiene comunicación directa con el servidor remoto, sino que todo el tráfico debe primero atravesar el servidor en campo. La comunicación impacta en la API REST expuesta desde el dispositivo Raspberry Pi y él continúa la propagación del mensaje.