Desarrollo y evoluci
´
on de sistema OES
incluyendo datalogger y software asociado
Development and evolution of OES system, datalogger equipment and associated software
Pablo Bertinat
†1
, Juan Salerno
†2
, Marcelo Castello
†3
, Rafael Oliva
∗4
†
Observatorio de Energ
´
ıa y Sustentabilidad (OES), UTN FRRO
Zeballos 1341 - Rosario - Santa Fe (Argentina)
1
pbertinat@frro.utn.edu.ar
2
jsalerno@frro.utn.edu.ar
3
mcastello@frro.utn.edu.ar
∗
Energ
´
ıas Alternativas / Instituto de Tecnolog
´
ıa Aplicada
Avda Gregores y Lero Rivera - R
´
ıo Gallegos - Santa Cruz (Argentina)
4
roliva@uarg.unpa.edu.ar
Abstract—This paper delineates the different stages in the
design and evolution of a datalogger system and its associated
software. It was developed within the framework of a Project
aimed at the study and processing of wind data for power
generation, and carried out with open source tools.
This project has focused on the development of in-house
technology, with capabilities and performance comparable to
equipment available on the market. Commercial off-the-shelf
systems have been analysed, as well as associated software in
order to set the general features and requirements for the
prototype.
An important number of industry-standard features in the
processing of wind data for electric power generation have
been considered. Hardware was developed and a web-based
system located in an in-house server have been deployed, both
of which work together to fulfill the proposed functions.
Keywords: datalogger; wind energy; measurements; software
Resumen— El presente trabajo detalla las etapas en el
dise
˜
no y la evoluci
´
on de un datalogger y su software asociado,
desarrollados en el marco de un Proyecto orientado al
relevamiento y procesamiento de datos de potencial e
´
olico con
fines energ
´
eticos mediante herramientas de acceso libre.
El presente proyecto se ha enfocado en el desarrollo y
ensayos de desempe
˜
no de un equipo de tecnolog
´
ıa propia,
que busca equiparar en prestaciones a los disponibles en
plaza. Para el dise
˜
no del equipo, se han examinado las
capacidades y el funcionamiento general de equipos disponibles
comercialmente con la finalidad de establecer las caracter
´
ısticas
generales que debe tener el prototipo.
Se analizaron las particularidades requeridas en el
procesamiento de la informaci
´
on del potencial e
´
olico para
la producci
´
on de energ
´
ıa el
´
ectrica. Se ha desarrollado un
conjunto de hardware y sistema web alojado en un servidor
propio que operan coordinadamente para cumplir las
funciones propuestas.
Palabras clave: datalogger; energ
´
ıa e
´
olica; mediciones;
software.
I. INTRODUCCI
´
ON
El
´
enfasis del desarrollo que se presenta, ha sido puesto
en el dise
˜
no de una cadena completa de medici
´
on -que
incluye hardware y software- para un sistema de adquisici
´
on
de datos orientado a mediciones meteorol
´
ogicas para apli-
caciones de energ
´
ıa e
´
olica seg
´
un el est
´
andar IEC [1]. Las
se
˜
nales m
´
as importantes, seg
´
un el an
´
alisis realizado en [2]
son las de intensidad y direcci
´
on de viento, temperatura
y presi
´
on atmosf
´
erica. En la normativa IEC se analizan
tambi
´
en aspectos relativos a la calibraci
´
on y tratamiento de
incertidumbres asociadas a la medici
´
on, cuya aplicaci
´
on para
equipos similares ha sido evaluada en [3] y en [4]. Varias
adaptaciones a condiciones locales se sugieren en [5].
La producci
´
on de equipamiento apto para mediciones de
viento es una tarea compleja, y a tal efecto se han anal-
izado equipos y paquetes de software aceptados y utilizados
habitualmente en la industria a nivel internacional. Se ha
trabajado con equipos de origen norteamericano NRG Sym-
phonie [6], provisto con el software b
´
asico de reportes Data
Retriever [7], los Vaisala-Nomad2 (antes de Secondwind) [8]
y su software asociado Nomad Desktop (todav
´
ıa obtenible
a trav
´
es de Vaisala en [9]), y con equipos de origen aleman
Ammonit [10]. En el campo de los dataloggers de precisi
´
on
se ha trabajado en la interfaz y programaci
´
on de los modelos
CR850, CR1000 y CR1000X de Campbell Scientific [11]
y su software asociado Loggernet [12]. Asimismo se ha
trabajado con el software Argentina Map desarrollado en
su momento por el CREE / Dr. H. Mattio [13] y sucesi-
vas versiones acad
´
emicas del software Windographer, hoy
propiedad de UL [14]. Si bien cada sistema se adapta a
aplicaciones espec
´
ıficas, una caracter
´
ıstica com
´
un en estos
productos es que se trata de desarrollos propietarios, algo
que se da en casi toda la industria de relevamiento e
´
olico.
Esto hace que los equipos y software disponibles en Ar-
gentina sean de origen extranjero, su utilizaci
´
on onerosa
y en gran medida atada a criterios t
´
ecnico-econ
´
omicos
externos, que requieren adaptaci
´
on y entrenamiento especial
en caso de cambios o actualizaciones. El impulso a una
alternativa de desarrollo de tecnolog
´
ıa propia destinada a
este fin, que pueda ser adaptada a las necesidades de usuarios
locales, y que utilice mayormente licencias abiertas (con la
consiguiente disminuci
´
on de costos) evitando la dependencia
tecnol
´
ogica en equipos y en software, es lo que ha generado
la presente propuesta de trabajo.
La posibilidad de generar energ
´
ıa mediante el viento
implica el previo conocimiento de una serie de condi-
Recibido: 15/10/20; Aceptado: 17/12/20
https://doi.org/10.37537/rev.elektron.5.1.110.2021
Creative Commons License - Attribution-NonCommercial-
NoDerivatives 4.0 International (CC BY-NC-ND 4.0)
Original Article
Revista elektron, Vol. 5, No. 1, pp. 45-55 (2021)
ISSN 2525-0159
45
ciones locales que son propias del sitio que se pretende
elegir para las instalaciones. Estas condiciones son diversas
y heterog
´
eneas, y es posible mencionar entre ellas: la
disponibilidad de los terrenos para el emplazamiento de
los molinos, la cercan
´
ıa y accesibilidad a las l
´
ıneas de
transmisi
´
on el
´
ectricas donde se insertar
´
an los generadores,
las condiciones locales de estas l
´
ıneas -tensi
´
on, capacidad,
potencia de cortocircuito, etc.- la accesibilidad de caminos
para la log
´
ıstica de traslado de equipos de construcci
´
on,
personal y los propios molinos, entre muchas otras. Pero las
de mayor incidencia para decidir la elecci
´
on de un sitio en
particular, son las condiciones del recurso e
´
olico disponible.
La evaluaci
´
on precisa y ajustada de este recurso y el efecto
multiplicador que sus posibles variaciones e incertidumbres
imprimen en los resultados energ
´
eticos y econ
´
omicos de la
futura instalaci
´
on, remarcan la importancia asignada y los
recursos empleados en lograr una alta previsibilidad en los
resultados. Mediante este aporte se espera poder mejorar
las condiciones para el aprovechamiento de esta fuente de
energ
´
ıa renovable as
´
ı como la generaci
´
on de capacidades
locales, tanto en cadenas de valor tecnol
´
ogico en el
´
area
como en el desarrollo del recurso humano necesario.
II. OBJETIVOS DEL PROYECTO
Partiendo de las premisas indicadas, puede mencionarse
como objetivo general, ya explicitado en el mencionado
trabajo de tesis [2] es el siguiente: alcanzar el desarrollo de
un prototipo de datalogger y un sistema de procesamiento
de informaci
´
on de licencias abiertas, que permitan adquirir,
transmitir, almacenar y analizar la informaci
´
on proveniente
de diversos tipos de sensores asociados a la medici
´
on de po-
tencial e
´
olico con fines energ
´
eticos. Los objetivos espec
´
ıficos
se pueden enumerar como sigue:
• Evaluar el desempe
˜
no de un equipo de tecnolog
´
ıa
propia, equivalente en prestaciones y calidad a los
disponibles en plaza, con las capacidades y adapta-
ciones necesarias para estudios locales.
• Desarrollar un sistema para la visualizaci
´
on en tiempo
real de las variables capturadas por el equipo datalog-
ger.
• Explorar, relacionar y desarrollar herramientas de
procesamiento de la informaci
´
on elaborada en base a
software no propietario con el hardware desarrollado.
Estos sistemas estar
´
an basados en tecnolog
´
ıa web y
podr
´
an estar disponibles a nivel global previa autenti-
caci
´
on de los usuarios.
El desarrollo de un datalogger es una tarea compleja,
m
´
as a
´
un cuando el objetivo implica crear un sistema com-
pleto que permita conocer las caracter
´
ısticas y el poten-
cial energ
´
etico de los vientos locales, con posibilidad de
tratamiento de la informaci
´
on recogida. Se entiende por
sistema en este caso al conjunto de equipo, el software y
una metodolog
´
ıa de trabajo. Dicho conjunto debe ser capaz
de analizar variables y crear gr
´
aficos que relacionen estas
variables, determinen potencial energ
´
etico y orienten hacia
la concreci
´
on de proyectos e
´
olicos.
III. ANTECEDENTES
El trabajo se ha llevado adelante en el marco del
Proyecto de Investigaci
´
on Homologado PID ”Desarrollo de
equipamiento y procesamiento de datos de potencial e
´
olico
con fines energ
´
eticos median herramientas de software
libre”, c
´
odigo ENUTIRO0002136TC, dirigido por Pablo
Bertinat. Antes de abordar el dise
˜
no, se han examinado
las prestaciones y el funcionamiento general de equipos
disponibles en plaza como los citados en I.) con la fi-
nalidad de determinar las caracter
´
ısticas generales que se
deben proveer. Se busc
´
o de esta forma encontrar los puntos
importantes y comunes que deben atenderse para establecer
funciones a incorporar en el dise
˜
no.
IV. DISCUSI
´
ON SOBRE LAS ALTERNATIVAS DEL
HARDWARE
Las premisas planteadas (consulta en tiempo real de las
mediciones, almacenamiento interno y configuraci
´
on on-
line), implican que se deb
´
ıa optar para la construcci
´
on
del sistema, por una arquitectura de hardware. Dentro de
las opciones disponibles se consideraron desde las Mi-
croPC (RaspberryPi, PandaBoard, Beagleboard, etc.) con
variantes de Linux hasta los microcontroladores de diversas
prestaciones (8 bits, 32 bits). Se le di
´
o especial importan-
cia al objetivo del equipo: la medici
´
on de las variables
meteorol
´
ogicas por sobre las otras premisas. Los tiempos
de procesamiento relativamente bajos y requerimientos de
simplicidad llevaron a elegir una arquitectura basada en
microcontrolador sin RTOS, trabajando en modalidad de
lazo infinito con temporizaci
´
on por interrupciones. Se opt
´
o
por una plataforma LPC1769 [15] (ARM Cortex M3) de
32 bits, espec
´
ıficamente utilizando la placa de desarrollo
LPCXpresso 1769 [16] de amplia disponibilidad. En la
figura 1 se aprecia la plataforma seleccionada. La combi-
naci
´
on de firmware y controlador seleccionada permite:
• Medici
´
on de variables en tiempo real.
• Utilizaci
´
on de bibliotecas de bajo nivel en C escritas
y mantenidas por el fabricante, con licencias flexibles,
que facilitan la escritura de la aplicaci
´
on.
• Acceso a herramientas de desarrollo gratuitas o de bajo
costo: IDE basado en Eclipse [17] compilador gcc [18],
programador y debugger LPC Link2 [19].
• Posibilidad a futuro de incorporar FreeRTOS [20] como
sistema operativo, dada la existencia de un port a dicho
microcontrolador y una importante base de usuarios.
Módulo LPC Link
Programador y debugger
Chip
Ethernet
EEPROM
256Kb
Microcontrolador
LPC1769
Fig. 1. LPCXpresso 1769 con microcontrolador Cortex M3, 32 bits
V. ARQUITECTURA DEL SISTEMA
El dise
˜
no del sistema completo requiere la coordinaci
´
on
del funcionamiento de diversos componentes. Para su expli-
caci
´
on puede ser dividido en dos partes fundamentales:
• Hardware y firmware del datalogger
Revista elektron, Vol. 5, No. 1, pp. 45-55 (2021)
ISSN 2525-0159
46
http://elektron.fi.uba.ar
• Comunicaci
´
on con servidor remoto
• Sistema de visualizaci
´
on y persistencia de datos
A. Hardware y firmware del datalogger
Observando el diagrama en bloques de la figura 2, puede
discriminarse su funcionamiento en los siguientes pasos:
1) Circuitos de entrada de se
˜
nales
2) Digitalizaci
´
on
3) Filtrado digital (en desarrollo)
4) Muestreo y procesamiento
5) Almacenamiento en RAM
6) Sincronizaci
´
on con SD
7) Procesador de comandos
1) Circuitos de entrada de se
˜
nales: Los circuitos
desarrollados realizan un tratamiento diferenciado para dos
tipos b
´
asicos de se
˜
nal a procesar: en primer lugar la se
˜
nal
de los anem
´
ometros que proporcionan una tensi
´
on de CA
de amplitud y frecuencia variable en un rango de 0 a 100
Hz, con informaci
´
on de velocidad de viento contenida en
la frecuencia, y por otro lado el resto de las se
˜
nales que
son del tipo anal
´
ogico y de variaci
´
on lenta. Los criterios
de dise
˜
no del hardware han contemplado la posibilidad de
agregar m
´
as canales tanto de frecuencia como anal
´
ogicos
en futuros desarrollos, para el caso de requerirse su empleo
en una torre con mayor cantidad de alturas de medici
´
on. El
modelo actual se desarroll
´
o para 2 alturas.
Las etapas de entrada de todas las se
˜
nales incorporan
filtrado anal
´
ogico activo. En el caso de los anem
´
ometros
se realiza un filtrado del tipo Sallen-Key de 2° orden,
y posteriormente se agrega una etapa de conformaci
´
on
de la onda necesaria para su tratamiento posterior. En la
figura 3 se puede apreciar el circuito del filtro mencionado
con su conformador de se
˜
nal. En el caso de las variables
anal
´
ogicas s
´
olo se incorpor
´
o un filtro activo de primer
´
orden. En la figura 4 se aprecia la secci
´
on anal
´
ogica del la
placa del datalogger.
2) Digitalizaci
´
on: Las se
˜
nales anal
´
ogicas provenientes
de los filtros, se aplican al subsistema de conversi
´
on
anal
´
ogico digital. Se utiliz
´
o el circuito integrado MCP3208
[21] , de Microchip, un conversor A/D de 12 bits de
aproximaciones sucesivas. Su tecnolog
´
ıa CMOS de muy
bajo consumo (500 nA t
´
ıpicos) permite su utilizaci
´
on en
circuitos alimentados por bater
´
ıas. Su rango de temperaturas
de trabajo, de -40 a +85ºC lo hacen apto para aplicaciones
industriales y de campo.
Se prefiri
´
o utilizar un conversor externo y no el integrado
en el microcontrolador por razones de escalabilidad para
futuras implementaciones que impliquen medici
´
on de mayor
cantidad de variables anal
´
ogicas. Al conectarse este chip al
microcontrolador a trav
´
es de un bus SPI es relativamente
simple el agregado de m
´
as dispositivos conversores.
En la figura 5 se pueden apreciar las dos unidades MCP3208
utilizadas para este proyecto.
3) Filtrado digital (en desarrollo): Se encuentra en
desarrollo una etapa de filtrado digital que permitir
´
a
analizar las se
˜
nales ingresadas, evaluando su pendiente.
Luego, en base a dicho valor el microcontrolador decide
para cada medici
´
on en base a las pendientes encontradas
hist
´
oricamente si incorpora o descarta ese valor. Por el
momento, s
´
olo se utiliza el filtro anal
´
ogico de la secci
´
on
de acondicionamiento de se
˜
nal.
4) Muestreo y Procesamiento: Se ha considerado
importante incorporar en el firmware la posibilidad
configurar los tiempos de muestreo y el de producci
´
on de
registros. Dichos tiempos se almacenan en dos variables:
• im: intervalo de muestreo.
Intervalo de tiempo entre cada medici
´
on (anal
´
ogica y
digital). Su valor por defecto es 1 seg.
• cr: cantidad de mediciones por registro.
Es la cantidad de mediciones necesarias para la
producci
´
on de un registro. Su valor por defecto es
600.
Los valores por defecto mostrados, son los que provienen
de la recomendaci
´
on de las mencionadas normas [1] y [5]
para equipos e
´
olicos en conexi
´
on a red.
El proceso realiza una lectura de cada canal de entrada en
el intervalo de tiempo determinado por im. A esta medici
´
on
se la denomina dato crudo, cuya estructura puede apreciarse
en la figura 6. Cuando la cantidad de mediciones llega a cr,
tiene lugar el procesamiento, que consiste en el c
´
alculo del
promedio, desv
´
ıo standard, m
´
aximo y m
´
ınimo a partir de
los datos crudos le
´
ıdos y para cada variable muestreada. Se
forma as
´
ı un registro, que est
´
a compuesto por los valores
procesados para cada canal de entrada, seg
´
un la estructura
que se aprecia en la figura 7.
5) Almacenamiento en RAM: Cada cr segundos, seg
´
un
la normativa utilizada se graba en memoria RAM el registro
de los datos generados.
6) Sincronizaci
´
on con SD: Se denomina as
´
ı al proceso
mediante el cual los registros de la RAM pasan a la
memoria SD extra
´
ıble. Si bien -como ya se ha dicho- el
equipo cuenta con transmisi
´
on de los datos medidos para
que sean guardados en una base de datos remota, tambi
´
en se
incorpora una tarjeta SD donde se almacenan los mismos.
Se le llama sincronizaci
´
on ya que mediante algoritmos de
control este proceso hace que el contenido de la RAM y
de la memoria externa SD sean id
´
enticos, no permitiendo
la falta ni la duplicaci
´
on de datos. Si por alguna raz
´
on
se interrumpe la escritura en SD, en el siguiente ciclo se
reanudar
´
a desde el
´
ultimo dato no almacenado.
7) Procesador de comandos: El firmware posee un
procesador de comandos accesible a trav
´
es de dos capas
f
´
ısicas posibles:
• Puerto USB
• Ethernet (Telnet)
Los comandos est
´
an agrupados seg
´
un su funci
´
on, siendo
ellas:
• Configuraci
´
on/Informaci
´
on
• Actuaci
´
on
• Gesti
´
on de SD
La sintaxis de los comandos es:
Revista elektron, Vol. 5, No. 1, pp. 45-55 (2021)
ISSN 2525-0159
47
http://elektron.fi.uba.ar
CAD
LPF
LPF
PHY
Serial
Almacenamiento
local
Configuración
Anemómetros
Variables
analógicas
Servidor
Base de
datos
Modem
GPRS
Microcontrolador LPC1769
Fig. 2. Diagrama de bloques del datalogger.
Fig. 3. Filtro y conformador de onda.
Fig. 4. Vista de la secci
´
on anal
´
ogica del PCB
comando [par
´
ametros][-h]
donde:
par
´
ametros es la lista de par
´
ametros con sus valores.
-h ayuda, cuando se especifica este par
´
ametro se muestra
una ayuda del comando.
Cuando no se especifica ning
´
un par
´
ametro el co-
Fig. 5. Conversores A/D MCP3208
mando actua como comando de informaci
´
on, si pertenece
al grupo Configuraci
´
on/Informaci
´
on. Algunos comandos
tienen par
´
ametros obligatorios: sms, ls, cd, tail
Los par
´
ametros van separados por espacios y precedidos
Revista elektron, Vol. 5, No. 1, pp. 45-55 (2021)
ISSN 2525-0159
48
http://elektron.fi.uba.ar
Fig. 6. Dato crudo
Fig. 7. Estructura de un registro
por el signo −, por ejemplo el comando rtc cambia/muestra
el estado del reloj de tiempo real, y la secuencia:
rtc -A 2020 -M 10 -D 12 -h 20 -m 15
ajusta la fecha y hora del reloj de tiempo real a:
12/10/2020 20:15
Las constantes de calibraci
´
on de los anem
´
ometros y otros
sensores se configuran a trav
´
es del comando sensconf y se
almacenan en EEPROM. En el caso de los anem
´
ometros,
estas constantes vienen frecuentemente certificadas por un
laboratorio externo de calibraci
´
on. Adem
´
as de ello, se realiza
una calibraci
´
on de bajo nivel en frecuencia para los canales
de viento del datalogger siguiendo un procedimiento similar
al indicado en [22], y en tensi
´
on para los canales anal
´
ogicos
utilizando instrumental de baja incertidumbre.
En las figuras 8 y 9 se pueden ver las salidas por terminal
de los comandos ifconfig y read respectivamente.
Fig. 8. Ayuda del comando de configuraci
´
on de red
Fig. 9. Resultado de la ejecuci
´
on del comando read
En la Tabla 1 se ven los comandos disponibles y sus
funciones.
VI. COMUNICACI
´
ON CON SERVIDOR REMOTO
Para que se puedan visualizar las mediciones en tiempo
real, es necesario que el datalogger se comunique con un
Revista elektron, Vol. 5, No. 1, pp. 45-55 (2021)
ISSN 2525-0159
49
http://elektron.fi.uba.ar
Tabla 1: Comandos disponibles
Comando Funci
´
on Decripci
´
on
help Info Muestra los comandos disponibles
ver Info Version del hardware/firmware
datastat Info Muestra estadisticas de la RAM y SD
read Info Muestra datos en tiempo real
systat Info Muestra el estado del sistema
rtc Info/config Muestra/configura reloj
sensconf Info/config Muestra/configura la funci
´
on de transferencia de los sensores
storeconf Info/config Muestra/configura almacenamiento de datos
ifconfig Info/config Muestra/configura la ethernet
id Info/config Muestra/configura las id origen-destino
gprs Info/config Muestra/configura el GPRS
exit Actuaci
´
on Exit shell
freset Actuaci
´
on Carga configuraciones por defecto
sms Actuaci
´
on Inicia envio de SMS
ls Gesti
´
on de SD Muestra el directorio
cd Gesti
´
on de SD Cambia el directorio
tail Gesti
´
on de SD Muestra ultimas n lineas del archivo
mount Gesti
´
on de SD Monta el sistema de archivos en la SD
umount Gesti
´
on de SD Desmonta el sistema de archivos de la SD
TABLE I
COMANDOS DISPONIBLES
servidor remoto donde se almacenan los datos medidos.
Para esta comunicaci
´
on se utiliz
´
o el modelo cliente-servidor,
lo cual requiri
´
o el desarrollo una capa de software que se
encargara de las comunicaciones de ambos lados: datalogger
y lado servidor.
Se analizaron las alternativas disponibles para lograr la
comunicaci
´
on:
• Servidor dentro de la LAN de medici
´
on
• Servidor fuera de la LAN de medici
´
on y datalogger
con redundancia de enlace
• Servidor fuera de la LAN de medici
´
on y datalogger v
´
ıa
GPRS
Finalmente se seleccion
´
o esta
´
ultima opci
´
on que incorpora
General Packet Radio Service(GPRS), por considerarla la
m
´
as adecuada. En la figura 10 se muestra un esquema de
aplicaci
´
on real del sistema, que re
´
une las ventajas del GPRS
en cuanto a simplicidad de configuraci
´
on, econom
´
ıa de
desarrollo y su disponibilidad y gran difusi
´
on en Argentina
(lo cual aumenta la posibilidad de instalar el sistema sin
repetidoras en buena parte del pa
´
ıs).
Para asegurar que no haya duplicaci
´
on ni p
´
erdida de datos
en el proceso de transmisi
´
on, la aplicaci
´
on implementa pro-
cesos de verificaci
´
on y validaci
´
on. En caso de interrupci
´
on
de la comunicaci
´
on, los datos persisten para ser enviados en
el pr
´
oximo ciclo de transmisi
´
on. Un algoritmo de marcas y
comprobaciones se ha implementado para tener un registro
de los datos efectivamente guardados en la base de datos.
As
´
ı, ante una falla en la transmisi
´
on, el sistema retoma la
sincronizaci
´
on sin p
´
erdida de datos ni duplicaci
´
on.
Existe tambi
´
en la posibilidad de recuperar los datos concur-
riendo al sitio del emplazamiento y extrayendo la tarjeta SD
del datalogger y efectuando su lectura desde una PC com-
patible. En la figura 11 se ven dos casos de comunicaci
´
on
entre el datalogger y el servidor. El de la izquierda ilustra
una comunicaci
´
on exitosa, mientras que en el de la derecha
se aprecia una falta de respuesta por parte del servidor, en
este caso el datalogger no registra la marca de dato grabado,
con lo cual en la pr
´
oxima sesi
´
on de transmisi
´
on lo har
´
a desde
Datalogger
Celda celular
Servidor remoto con
almacenamiento
Clientes que
visualizan
Módulo
GPRS
Firewall
Router
Fig. 10. Diagrama de enlace con GPRS
el dato que no pudo concretar la grabaci
´
on.
Como se mencion
´
o previamente, la figura 2 muestra el
esquema general del sistema. En el bloque nominado como
”servidor” se aloja el sistema web que permite realizar
las representaciones que se detallar
´
an en los par
´
agrafos
siguientes.
VII. SISTEMA DE VISUALIZACI
´
ON Y PERSISTENCIA DE
DATOS
Se realizar
´
a la explicaci
´
on de esta secci
´
on con una dis-
criminaci
´
on en capas, para su mejor comprensi
´
on. La figura
12 muestra el diagrama conceptual de las capas de software
que componen el sistema.
Siempre pensando que cada capa es una porci
´
on de
software, se observa que esta disposici
´
on no discrimina
en qu
´
e plataforma se est
´
a ejecutando cada capa. Esto se
debe a que el diagrama sugiere interpretar cual es la l
´
ogica
puesta en juego en todo el proceso de medici
´
on, hasta la
Revista elektron, Vol. 5, No. 1, pp. 45-55 (2021)
ISSN 2525-0159
50
http://elektron.fi.uba.ar
Datalogger Servidor
Establece comunicación
con servidor
Lee desde SD el último
dato transmitido
Acepta
comunicación
Empaqueta el próximo
dato y lo envía
Desempaqueta,
valida y graba en
BD
OK
Guarda en SD puntero
del ultimo dato
efectivamente guardado
en BD
Establece comunicación
con servidor
Acepta
comunicación
Lee desde SD el último
dato transmitido
Empaqueta el próximo
dato y lo envía
Desempaqueta,
valida y graba en
BD
Error
Sin respuesta
(timeout)
Sale sin confirmar
Datalogger Servidor
Fig. 11. Sincronizaci
´
on con servidor remoto
visualizaci
´
on de los resultados. Mediante la aplicaci
´
on de
este concepto, se concluye que la entrada al sistema son las
variables f
´
ısicas y la salida o resultado es la visualizaci
´
on
de estas variables.
A. Capa 1
Esta capa se refiere al firmware que corre en el mi-
crocontrolador del datalogger, que se encarga de mane-
jar el conversor A/D, procesar las variables para obtener
promedios, m
´
aximos, m
´
ınimos y desv
´
ıo est
´
andar y gestiona
la grabaci
´
on de la SD (con sistema de archivos FAT ).
Asimismo administra las comunicaciones ya sea por capa
f
´
ısica ethernet (v
´
ıa protocolo TCP/IP ) o GPRS. Tambi
´
en
posee un procesador de comandos utilizado para la config-
uraci
´
on y comunicaci
´
on. Est
´
a escrita en lenguaje C .
B. Capa 2
Esta capa, escrita en lenguaje Python [23], es la encargada
de la interface entre el datalogger y el servidor de base
de datos donde se almacenar
´
an las variables procesadas
(Di
´
alogo M2M = di
´
alogo m
´
aquina a m
´
aquina). Se encarga
de gestionar la comunicaci
´
on desde el lado fijo (servidor),
validar los paquetes (datos formateados) que llegan desde
el datalogger y guardarlos en la base de datos. Posee un
algoritmo de confirmaci
´
on para evitar la p
´
erdida de datos
por falla en la capa f
´
ısica.
C. Capa 3
Es el motor de base de datos MySQL [24] que se encarga
de recibir los datos de la capa anterior y efectivizar el
almacenamiento en el hardware del servidor.
D. Capa 4
Esta capa constituye el sistema web, y es la encargada de
mostrar los datos medidos, ya sea en forma de gr
´
aficos tem-
porales (velocidad del viento, temperatura, etc.) o gr
´
aficos
espec
´
ıficos (rosa de los vientos, distribuci
´
on estad
´
ıstica de
Weibull, etc.). Muestra tambi
´
en de manera simple e intuitiva
los
´
ultimos datos medidos por el datalogger, y la posici
´
on
geogr
´
afica del mismo (o los mismos, ya que el sistema se ha
dise
˜
nado para albergar varios equipos). Posee formularios
para la configuraci
´
on del sistema en general. Tambi
´
en es
posible elegir los entornos de tiempo de graficaci
´
on y
c
´
alculo de resultados especiales. Est
´
a desarrollada en los
siguientes lenguajes de programaci
´
on: PHP [25] , Javascript
[26] , HTML [27]. Para las representaciones gr
´
aficas se han
utilizado las bibliotecas de acceso libre Highcharts [28],
escritas en Javascript.
Visualización de resultados
Base de datos
Diálogo M2M
Firmware
Variables físicas
Capa 4
Capa 3
Capa 2
Capa 1
Sistema Web
MySQL
Lenguaje Python
Lenguaje C
Fig. 12. Diagrama de capas del software del sistema.
VIII. RESULTADOS Y PRESENTACI
´
ON DE LA
INFORMACI
´
ON
Para presentar la informaci
´
on obtenida de las mediciones
que procesa el datalogger, se ha creado un sitio web. El
acceso al mismo se logra a trav
´
es de autenticaci
´
on con
usuario y contrase
˜
na.
La intenci
´
on es que el usuario habituado al uso de apli-
caciones en dataloggers comerciales encuentre familiares
Revista elektron, Vol. 5, No. 1, pp. 45-55 (2021)
ISSN 2525-0159
51
http://elektron.fi.uba.ar
Fig. 13. P
´
agina inicial del sistema de visualizaci
´
on
los gr
´
aficos e informaciones contenidas y se maneje con
solvencia con una m
´
ınima adaptaci
´
on. Dado que el data-
logger se encontrar
´
a en servicio activo en el sistema, la
idea b
´
asica es que pueda accederse a la medici
´
on online,
en tiempo real, puedan observarse los valores que se est
´
an
midiendo, adem
´
as de obtener los datos y a partir de ellos
trabajar en el reporte que se necesite. Tambi
´
en, como
eventualmente habr
´
a varios equipos operativos dentro del
sistema, se ha establecido una identificaci
´
on de los mismos
de modo inequ
´
ıvoco.
Men
´
u de inicio
Al ingresar al sitio se observa un mapa de ubicaci
´
on
de los diferentes dataloggers (o eventualmente estaciones
meteorol
´
ogicas, u otros equipos) disponibles, cuyas co-
ordenadas geogr
´
aficas se pueden ingresar. Esta instancia
se ha elaborado aprovechando las facilidades de Google
Maps, y la idea es que all
´
ı puedan observarse las diferentes
mediciones para los que se ha pensado el sitio. El proyecto
integral contempla la capacidad de brindar operatividad al
funcionamiento de un conjunto de estaciones que volcar
´
an
las mediciones en este sitio. Se ha trabajado en este dise
˜
no
para ser empleado en el Proyecto PRIER [29]. La figura 13
muestra la p
´
agina inicial del sitio web.
Los puntos de medici
´
on se se
˜
nalan mediante un marcador, y
cierta informaci
´
on acerca del mismo se anota en una se
˜
nal
tipo burbuja u otra de uso habitual en maps (por ejemplo
coordenadas, denominaci
´
on del sitio u otro que sirva de
referencia).
Representaciones gr
´
aficas de las salidas del sistema
Velocidades de vientos: Examinando la pesta
˜
na de
gr
´
aficos, lo primero que se observa en este men
´
u es la gr
´
afica
de vientos, esto es, la representaci
´
on de los promedios de
velocidades cada 10 minutos (o intervalo seleccionado), de
los anem
´
ometros instalados en el sitio. En este caso son
dos, y las gr
´
aficas son en dos colores, permitiendo mediante
la localizaci
´
on del puntero obtener el detalle de las dos
velocidades y la hora del correspondiente registro, como se
puede apreciar en la figura 14.
Pueden seleccionarse las fechas de inicio y finalizaci
´
on de
la gr
´
afica. Adem
´
as existe la posibilidad de hacer un zoom
temporal en el gr
´
afico (mediante el eje inferior), desde una
hora hasta un a
˜
no, o mostrar toda la informaci
´
on disponible.
Fig. 14. Gr
´
afico de series de vientos.
Rosa de vientos: La rosa de vientos de frecuencia se
obtiene en la siguiente opci
´
on de la pesta
˜
na de gr
´
aficos. Se
Revista elektron, Vol. 5, No. 1, pp. 45-55 (2021)
ISSN 2525-0159
52
http://elektron.fi.uba.ar
Fig. 15. Gr
´
afico de rosa de vientos.
observa que adem
´
as de definir el rango temporal se puede
asignar un entorno de velocidades, y una Vmin (velocidad
m
´
ınima) a representar. Este entorno en [m/s] implica la
subdivisi
´
on del total de mediciones que corresponde a cada
sector de la rosa. La Vmin es el valor de la velocidad reg-
istrada por encima del cual se realizar
´
a el gr
´
afico, es decir,
se descartar
´
an las velocidades por debajo de ella. Existe
la posibilidad de obtener una rosa de vientos tradicional,
mediante el recurso de asignar un entorno que abarque a
todas las velocidades medidas (el dato de velocidad m
´
axima
Vmax siempre aparece explicitado). Se observa por ejemplo
en la figura 15 (derecha), que la ocurrencia total para el
sector ESE ha sido del 8,44%. Se han descartado los vientos
menores a 0,5 m/s.
Adem
´
as de esta rosa de vientos est
´
andar, es posible
configurar el entorno, y obtener una representaci
´
on que
resulte m
´
as
´
util para la aplicaci
´
on deseada. Por ejemplo,
ajustando el entorno en 2 m/s (figura 15 izquierda), se
observa en la pantalla que para los valores de ocurren-
cia porcentual en cada sector de direcci
´
on del viento, el
segmento representativo se subdivide a su vez en sectores
diferenciados por colores que representan el porcentaje de
viento de ese rango que ha sido configurado. En pantalla
puede apreciarse (ubicando el cursor) que para el sector
predominante, SE, la participaci
´
on de los vientos de entre
4,5 y 6,5 m/s es del 3.073%
Condiciones meteorol
´
ogicas: temperatura, presi
´
on y
humedad: Se muestra en la figura 16, la temperatura prome-
dio cada diez minutos. El cursor permite ver los valores
particulares con exactitud.
Fig. 16. Gr
´
afico de series de tiempos de temperatura.
Variables f
´
ısicas en tiempo real: En esta pesta
˜
na el
sistema permite visualizar las variables en tiempo real, a
partir de la
´
ultima medici
´
on efectuada, esto es, el
´
ultimo
dato le
´
ıdo y calculado. Se ha elegido desde Highcharts
[28] mostrar una representaci
´
on de r
´
apido impacto visual
(speedometer), mostrada en la figura 17. Se trata de una
visualizaci
´
on alternativa para las mediciones de la velocidad
y la direcci
´
on del viento representada seg
´
un un eje temporal,
que se han expuesto arriba, y que tiene la utilidad de ubicar
el estado general de la medici
´
on de modo inmediato.
Fig. 17. Variables en tiempo real anem
´
ometro 1.
Intensidad de turbulencia: La intensidad de turbulencia,
descripta en la ecuaci
´
on 1, es un dato de importancia, que
debe atenderse ya que junto a los vientos extremos afecta
dos aspectos claves en el dise
˜
no de un parque e
´
olico: el
aprovechamiento energ
´
etico del recurso y la fatiga mec
´
anica
de los materiales de los aerogeneradores. Es posible a
trav
´
es del sistema realizar una adecuada estimaci
´
on (en una
dimensi
´
on) de estos valores, mediante el c
´
alculo:
IT =
σ
10
υ
10
(1)
donde:
σ
10
: desv
´
ıo standard en un per
´
ıodo de 10 minutos
υ
10
: velocidad promedio en un per
´
ıodo de 10 minutos.
Tanto los promedios de velocidades de viento como el
Revista elektron, Vol. 5, No. 1, pp. 45-55 (2021)
ISSN 2525-0159
53
http://elektron.fi.uba.ar
desv
´
ıo est
´
andar para cada per
´
ıodo de 10 minutos han sido
calculados, con lo cual se puede construir la gr
´
afica (figura
18) que se muestra en la pesta
˜
na gr
´
aficos-intensidad de
turbulencia. Puede seleccionarse all
´
ı el rango temporal que
se desea para la representaci
´
on.
Fig. 18. Intensidad de turbulencia.
Distribuci
´
on estad
´
ıstica de Weibull: Siendo el viento
una variable aleatoria continua, para su estudio deben or-
ganizarse los datos medidos. La funci
´
on de densidad de
probabilidad de Weibull II, de valores positivos, asim
´
etrica
y biparam
´
etrica, es la que mejor se ajusta para este tipo de
estudio seg
´
un lo visto en [2]. En el sistema OES es posible
seleccionar en la pesta
˜
na de gr
´
aficos esta funci
´
on, y elegir el
rango de fecha para los datos. Se calculan autom
´
aticamente
los par
´
ametros c [m/s] y k [] de dicha distribuci
´
on, con los
datos de cada anem
´
ometro, como se muestra en la figura 19.
De los m
´
etodos habitualmente utilizados, se ha seleccionado
el de los m
´
ınimos cuadrados.
Fig. 19. Gr
´
afica de Weibull.
IX. CONCLUSIONES Y TRABAJOS FUTUROS
La evaluaci
´
on del recurso e
´
olico de un sitio, como pre-
supuesto para el desarrollo de parques e
´
olicos, se encuentra
en el inicio de toda pol
´
ıtica de inserci
´
on de energ
´
ıas ren-
ovables. El prop
´
osito del presente trabajo es que tienda a
facilitar herramientas para lograr un cambio en la matriz
energ
´
etica del pa
´
ıs, que se oriente -tal como las pol
´
ıticas
nacionales impulsadas actualmente lo proclaman- a una
inserci
´
on significativa y sostenida de energ
´
ıas renovables
en dicha matriz. Existe una frontera imprecisa entre las
funciones que debe brindar un datalogger y su sistema
asociado de gesti
´
on de la informaci
´
on que se obtiene en
un sitio de inspecci
´
on del recurso e
´
olico, y las funciones
de an
´
alisis profundo de dicha informaci
´
on con la finalidad
de evaluar la calidad del sitio de generaci
´
on e
´
olica. Al
avanzar en el Proyecto se transit
´
o sobre esta frontera, y
por momentos no quedaba claro el l
´
ımite del desarrollo
y qu
´
e deber
´
ıa reservarse para futuros Proyectos. Se ha
buscado que el resultado fuese similar al que se obtiene
de otros dataloggers, y poder de alguna manera comparar
estos resultados, para evaluar los propios logros en el trabajo
realizado. Analizando los objetivos propuestos en el presente
trabajo, se observa que muchos de ellos se pudieron alcanzar
satisfactoriamente y que el proyecto ha permitido poner
en pr
´
actica conocimientos adquiridos en varios Proyectos
anteriores y exitosos del Grupo OES. Como continuaci
´
on del
trabajo presentado, se ha propuesto profundizar el estudio
y la evaluaci
´
on de las incertidumbres introducidas en la
medici
´
on del sistema dise
˜
nado, tarea indispensable para la
validaci
´
on del equipo, y en la que el Grupo se encuentra
trabajando en la actualidad.
REFERENCES
[1] IEC Standard (2017) IEC 61400-12-1 Wind energy generation systems
- Part 12-1: Power performance measurements of electricity producing
wind turbines. https://webstore.iec.ch/publication/26603
[2] Salerno, Juan (2017), Tesis de Maestr
´
ıa: Dise
˜
no de herramien-
tas propias para evaluar el potencial e
´
olico local - Desarrollo de
equipamiento y procesamiento de datos software libre. Defensa
08/2019 ResGate DOI: 10.13140/RG.2.2.17863.73128
[3] Oliva, R. (2014), Evaluaci
´
on de incertidumbre en medi-
ciones de potencia el
´
ectrica en registradores autom
´
aticos.
http://www.sase.com.ar/2014/congreso-argentino-de-sistemas-
embebidos-case-2014/
[4] Oliva, R.; Mart
´
ın, G.; Duzdevich, J.; Zappa, A. (2013) Evaluaci
´
on de
Incertidumbres de medici
´
on en Plataforma de Ensayo para peque
˜
nos
aerogeneradores, AVERMA Vol. 17, pp.06.11-06.20, ISSN 2314-1433
https://bit.ly/2UTnx8C
[5] Mattio, H. T. (2009). Recomendaciones para mediciones de velocidad
y direcci
´
on de viento con fines de generaci
´
on el
´
ectrica, y medici
´
on
de potencia el
´
ectrica generada por aerogeneradores. Buenos Aires:
Secretar
´
ıa de Energ
´
ıa.
[6] https://www.nrgsystems.com/products/data-
loggers/detail/symphonieplus3-data-logger
[7] https://www.nrgsystems.com/support/product-
support/software/symphonie-data-retriever-software
[8] http://wind-think.com/nomad-2-data-logger/
[9] http://forms.vaisala.com/nomad-desktop
[10] https://www.ammonit.com/en/support/9-ammonit-
produkte/datalogger/109-data-logger-wind
[11] https://www.campbellsci.com/data-loggers
[12] https://www.campbellsci.com/loggernet-admin
[13] https://core.ac.uk/download/pdf/325984495.pdf
[14] https://www.ul.com/resources/apps/windographer
[15] LPC1769 NXP Semic.:https://www.nxp.com/products/processors-
and-microcontrollers/arm-microcontrollers/general-purpose-
mcus/lpc1700-cortex-m3/512kb-flash-64kb-sram-ethernet-usb-
lqfp100-package:LPC1769FBD100
[16] https://www.embeddedartists.com/products/lpc1769-lpcxpresso/
[17] Integrated Developing Environment. Herramienta de desarrollo
basada en Eclipse: https://www.eclipse.org/ide/
[18] GNU C Compiler, compilador de c
´
odigo C licencia GPL
abierta: https://developer.arm.com/tools-and-software/open-source-
software/developer-tools/gnu-toolchain/gnu-rm/downloads
[19] Programador-depurador integrado LPC-Link2:
https://www.nxp.com/design/microcontrollers-developer-resources/lpc-
microcontroller-utilities/lpc-link2:OM13054
[20] FreeRTOS Sistema operativo de tiempo real de licencia abierta:
https://www.freertos.org/
[21] MCP3208, Microchip:
https://www.microchip.com/wwwproducts/en/MCP3208
[22] Oliva, R. (2014) Tesis Maestr
´
ıa: Estacion meteorol
´
ogica de con-
strucci
´
on modular orientada a la prospecci
´
on e
´
olica en Argentina.
ResGate DOI: 10.13140/RG.2.2.24096.33289
[23] Python (1991) - lenguaje de programaci
´
on de alto nivel ampliamente
utilizado, autor Guido Van Rossum: https://www.python.org/
[24] MySQL Sistema de gesti
´
on de base de datos de c
´
odigo abierto.
Propiedad de Oracle Corp.https://www.mysql.com/
Revista elektron, Vol. 5, No. 1, pp. 45-55 (2021)
ISSN 2525-0159
54
http://elektron.fi.uba.ar
[25] PHP lenguaje de scripting de lado servidor/cliente, orientado a
objetos. Creado por Rasmus Lerdorf en 1994https://www.php.net/
[26] JavaScript Implementaci
´
on de ECMAScript, primera version 1995.
https://www.ecma-international.org/publications/standards/Ecma-
262.htm
[27] HTML5 Versi
´
on mas reciente de Hypertext Markup Language:
https://html.spec.whatwg.org/multipage/
[28] Bibliotecas de graficaci
´
on HighCharts: https://www.highcharts.com/
[29] PRIER (Proyecto de Generaci
´
on Distribuida con Energ
´
ıas Renov-
ables) un Proyecto piloto de generaci
´
on el
´
ectrica con paneles fo-
tovoltaicos promovido por la UTN, la Cooperativa de Provisi
´
on
de Obras y Servicios P
´
ublicos de Armstrong y el INTI con el
apoyo de la Agencia Nacional de Promoci
´
on Cient
´
ıfica y Tec-
nol
´
ogica, CAMMESA y la Subsecretar
´
ıa de Energ
´
ıa de la Naci
´
on.
http://www.celar.com.ar/index.php/prier
Revista elektron, Vol. 5, No. 1, pp. 45-55 (2021)
ISSN 2525-0159
55
http://elektron.fi.uba.ar

Enlaces de Referencia

  • Por el momento, no existen enlaces de referencia


Copyright (c) 2020 Juan Salerno

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

Revista elektron,  ISSN-L 2525-0159
Facultad de Ingeniería. Universidad de Buenos Aires 
Paseo Colón 850, 3er piso
C1063ACV - Buenos Aires - Argentina
revista.elektron@fi.uba.ar
+54 (11) 528-50889