De onderzoekslocatie ligt aan de rand van een plateau-achtige vereffeningsrest op de overgang naar het beekdal van de Slinge, binnen de oude dorpskern van Winterswijk.
De locatie heeft een hoge archeologische trefkans op archeologische resten uit de periode Vroege Middeleeuwen – Nieuwe Tijd. Daarnaast kunnen ook bewoningssporen uit eerdere periodes, vanaf het Mesolithicum, worden verwacht

Albisu, Iñaki

Araneta, Juan Pablo

Cisneros, Federico

Finochietto, José Mariano

Garin, Juan Manuel

Robetto, José

Archaeological Research en Consultancy

Hebinck, K.A.

Electronic Archiving System

Een archeologisch bureau-onderzoek voor de locatie Wooldstraat 33 te Winterswijk (Gld)

Uno de los sistemas de riego que más creció en superficie regada en la última década en Argentina es el pivote central. Este sistema de riego por aspersión está conformado por una pirámide en el centro, y una serie de tramos enlazados que giran alrededor de la misma esparciendo agua y formando un círculo. Los caudales de agua utilizados varían según el cultivo y la configuración del equipo, pero es común que alcancen los 120.000 lt/h o más. Al ser equipos que operan de manera autónoma por varios días, no requieren de personas en el lote. Sin embargo, se realizan rondas de supervisión diarias ya que cualquier desperfecto en el equipo puede resultar en grandes pérdidas. Por ejemplo, si el equipo no avanza porque sus ruedas patinan en el barro y la bomba sigue funcionando con un caudal como el descrito, se estarían desperdiciando miles litros de agua dulce por hora que podrían utilizarse para otros consumos.
Existen alternativas a las rondas de supervisión para conocer el estado de los equipos sin tener que viajar al campo, pero tienen dos características que dificultan la adopción por parte de los productores. La primera es que dependen de una infraestructura de comunicación que en muchas zonas de Argentina no está disponible. Estas necesitan de cobertura celular o WiFi en el lote o en las proximidades del mismo, ya sea para enviar alertas SMS, para comunicarse desde el lote a un servidor en Internet, o para comunicarse con un nodo cercano mediante RF y utilizarlo como gateway a Internet. La segunda es que muchos de estos productos son provistos por los mismos fabricantes de equipos de riego y sólo funcionan en algunos modelos.
Este trabajo presenta el diseño e implementación de un sistema de Internet de las Cosas que permite monitorear el estado de un pivote central. Se adapta a cualquier modelo, y puede instalarse en cualquier lote de Argentina.Sociedad Argentina de Informática e Investigación Operativ

El Servicio de Difusión de la Creación Intelectual

Sistema de monitoreo remoto versátil para riego por
pivote central
Iñaki Albisu1, Juan Pablo Araneta12, Federico Cisneros1, José Mariano Finochiet-
to123, Juan Manuel Garin1 y José Robetto12
1 PONCE, Mar del Plata 7600, Argentina
{i.albisu, j.araneta, m.finochietto, j.robetto}
@ponceautomations.com
2 Universidad CAECE, Mar del Plata 7600, Argentina
3 GIDI, Departamento de Informática, Universidad Nacional de Mar del Plata,
Mar del Plata 7600, Argentina
mariano.fino@fi.mdp.edu.ar
Palabras Claves: Internet de las Cosas, agricultura sustentable
1   Introducción
Uno de los sistemas de riego que más creció en superficie regada en la última dé-
cada en Argentina es el pivote central [1]. Este sistema de riego por aspersión está
conformado por una pirámide  en el  centro,  y una serie  de tramos enlazados  que
giran alrededor de la misma esparciendo agua y formando un círculo. Los caudales
de agua utilizados varían según el cultivo y la configuración del equipo, pero es co -
mún que alcancen los 120.000 lt/h o más. Al ser equipos que operan de manera au -
tónoma por varios días, no requieren de personas en el lote. Sin embargo, se realizan
rondas de supervisión diarias ya que cualquier desperfecto en el equipo puede re -
sultar en grandes pérdidas. Por ejemplo, si el equipo no avanza porque sus ruedas
patinan en el barro y la bomba sigue funcionando con un caudal como el descrito, se
estarían desperdiciando miles litros de agua dulce por hora que podrían utilizarse
para otros consumos.
Existen  alternativas  a  las  rondas de  supervisión  para  conocer  el  estado  de los
equipos sin tener que viajar al campo, pero tienen dos características que dificultan
la adopción por parte de los productores. La primera es que dependen de una infra -
estructura de comunicación que en muchas zonas de Argentina no está disponible
[2]. Estas necesitan de cobertura celular o WiFi en el lote o en las proximidades del
mismo, ya sea para enviar alertas SMS, para comunicarse desde el lote a un servidor
en Internet, o para comunicarse con un nodo cercano mediante RF y utilizarlo como
gateway a Internet. La segunda es que muchos de estos productos son provistos por
los mismos fabricantes de equipos de riego y sólo funcionan en algunos modelos.
Este trabajo presenta el diseño e implementación de un sistema de Internet de las
Cosas  [3]  que  permite  monitorear  el  estado  de  un  pivote  central.  Se  adapta  a
cualquier modelo, y puede instalarse en cualquier lote de Argentina.
TAIC, Taller Argentino de Internet de las Cosas
48JAIIO - TAIC - ISSN: 2683-8982 - Página 9
2   Materiales y métodos
El sistema  puede organizarse  mediante  las  cinco  capas  arquitectónicas  [3]  co-
múnmente utilizadas para estructurar un sistema de Internet  de las Cosas: percep -
ción,  transporte,  procesamiento,  aplicación  y negocio.  Para simplificar  el  análisis
del diseño del sistema, no se incluye la capa de negocios y algunos servicios (como
las notificaciones SMS), y tampoco se detallan los algoritmos de detección de fallas.
La Figura 1 muestra los componentes principales,  y a continuación se describen las
capas.
Fig. 1. Diagrama de capas de la solución con orientación horizontal
a) Capa percepción: El desafío principal en esta capa es el de diseñar un sistema
de  sensores  que  pueda  ser  utilizado  en  cualquier  pivote  central  (interoperable).
Luego de analizar productos similares [4], se determinó utilizar un receptor GPS en
la punta de los tramos y un sensor de presión en el caño principal de agua del equi -
po. El receptor GPS es la placa open source SODAQ ONE v3 [5] alimentado con un
panel solar de 1 WATT, el cuál envía la posición periódicamente a un gateway dise -
ñado especialmente para este proyecto. El gateway se alimenta del tablero principal
del pivote, y tiene conectado el sensor de presión a una entrada analogica de su mi-
crocontrolador ATMEGA2560. Con la posición se determina su ubicación y si se
está moviendo, y con el sensor de presión si hay agua fluyendo.
b) Capa transporte: Dos puntos importantes  a  resolver  en esta  capa  incluyen
cómo comunicar el receptor GPS con el gateway, teniendo en cuenta que puede ha-
ber cientos de metros de distancia entre ambos, y cómo enviar los datos del campo a
un servicio remoto, considerando que el lote puede no contar con señal celular ni
servicio de Internet. Para el primer caso, se resolvió utilizar LoRa, un protocolo RF
que tiene un alcance teórico mayor a 30 km [6]. Para el segundo caso, se escogió la
comunicación satelital ya que esta garantiza conectividad en cualquier ubicación a
cielo abierto sin necesidad de montar una infraestructura aparte. El proveedor elegi-
do fue SkyWave que cuenta con una red de satélites geoestacionarios llamada Isat -
TAIC, Taller Argentino de Internet de las Cosas
48JAIIO - TAIC - ISSN: 2683-8982 - Página 10
Data Pro (IDP) con cobertura en la región. El gateway, entonces, arma un paquete
con datos de presión y posición, y los envía al satélite cada 15 minutos, para que
luego sean consumidos por una interfaz REST. El período de envío se eligió consi-
derando los costos del servicio satelital y la necesidad de negocio.
c) Capa procesamiento: El objetivo de esta  capa es procesar  y almacenar  los
datos que llegan desde el campo, para determinar si el equipo de riego está apagado,
regando o en falla. Al estar en una fase experimental, es importante poder aumentar
o disminuir fácilmente los recursos necesarios para el procesamiento. Se optó por
montar un ambiente  serverless, en el cuál el proveedor asigna los recursos necesa-
rios para ejecutar el código de manera dinámica [7]. Puntualmente se eligió un mo-
delo FaaS (Function-as-a-Service), donde el código que se envía al servidor es una
función asociada con un activador. Como proveedor, se optó por Google Cloud Plat -
form, debido a que ya se contaba con experiencia en su uso, y los productos utili -
zados fueron Cloud Functions como herramienta FaaS y Cloud PubSub como sis-
tema de mensajería y activadores. Para almacenar tanto los paquetes sin procesar (a
modo de copia de seguridad) y los estados ya procesados, se eligió  Keen.io que es
un servicio robusto de almacenamiento y consulta de eventos, el cual permite  aso-
ciar  dichos datos  con una  fecha  y hora  para  optimizar  consultas  con parámetros
temporales.
d) Capa aplicación: Se relevaron cuatro requerimientos que se destacan. El pri-
mero es que se debe poder acceder desde un teléfono celular ya que el productor ag -
rícola no siempre está en su oficina. El segundo involucra la interoperabilidad por lo
que debe funcionar en gran variedad de modelos y marcas de celular (smartphones).
El tercero es que la interfaz gráfica debe reflejar rápidamente los cambios de estado
del  riego  de  manera  automática.  Y el  cuarto  es  que  se  debe  poder  consultar  la
información aún cuando no haya conexión a Internet, por ejemplo en el campo. Para
resolver  las primeras dos cuestiones se desarrolló una aplicación web adaptable a
distintos  tamaños  de  pantalla,  lo  que  permite  utilizar  cualquier  celular  moderno
como cliente.  Para las otras dos, se utilizó la base de datos NoSQL Firestore, que
mediante WebSockets actualiza a los clientes cuando detecta un cambio en sus do-
cumentos,  y  se  optó  por  desarrollar  la  aplicación  como PWA (Progressive  Web
Applications) con caché en el cliente.
3   Resultados
La Figura 2 muestra imágenes de los resultados del diseño e implementación del
sistema propuesto, que comenzó en mayo de 2018 y culminó en marzo de 2019. En
total,  se  monitorearon  59  equipos  de  5  marcas  distintas:  Valley,  Lindsay,  T-L,
Montenegro y Rockink. La distancia más larga entre el receptor GPS y el gateway
fue de 770 m mientras que la más corta fue de 282 m. Los mismos estuvieron distri -
buidos en la Provincia de Buenos Aires, procesando más de 8.035.200 bytes prove-
nientes del gateway y detectando 144 fallas verificadas por los usuarios.
TAIC, Taller Argentino de Internet de las Cosas
48JAIIO - TAIC - ISSN: 2683-8982 - Página 11
(a) (b) (c) (d)
Fig. 2. Implementación del sistema: (a) foto del gateway en campo, (b) foto de la
placa del gateway, (c) foto del receptor GPS en campo y (d) captura de la aplicación
4   Conclusiones
Se presentó una propuesta de sistema de Internet  de las Cosas y su implemen -
tación, aplicada a una problemática del agro. Entre los desafíos futuros se encuen-
tran monitorear nuevos modelos de pivote en nuevas regiones del país y mejorar la
calidad del servicio en base al análisis de los datos recolectados en esta experiencia.
Además, se trabajará en cómo utilizar los datos disponibles para agregar más funcio-
nalidad y en incorporar nuevos sensores migrando a un estándar como LoRaWAN.
Referencias
1. UTF/ARG/017/ARG Desarrollo Institucional para la Inversión: Estudio del potencial de
ampliación del riego en Argentina. FAO. ISBN 9789253089956. (2015)
2. ENACOM. Mapa de conectividad nacional.  https://indicadores.enacom.gob.ar/MapasCo-
nectividad.aspx
3. Sethi, Pallavi, and Smruti R. Sarangi. Internet of Things: Architectures, Protocols, and
Applications. Journal of Electrical and Computer Engineering 2017 (2017) 1-25
4. Peters, R. T., and S. R. Evett. Using Low-Cost Gps Receivers For Determining Field
Position Of Mechanized Irrigation Systems. Applied Engineering in Agriculture 21, no. 5
(2005) 841-45
5. SODAQ ONE. 10/7/2019, de SODAQ. https://support.sodaq.com/sodaq-one/sodaq-on
6. Ray, Partha Pratim. Internet of Things for Smart Agriculture: Technologies, Practices and
Future  Direction.  Journal  of  Ambient  Intelligence  and  Smart  Environments  9,  no.  4
(2017) 395-420
7. Eyk,  Erwin Van, Lucian Toader,  Sacheendra  Talluri,  Laurens  Versluis,  Alexandru Uta,
and Alexandru Iosup. Serverless Is More: From PaaS to Present Cloud Computing. IEEE
Internet Computing 22, no. 5 (2018) 8-17
TAIC, Taller Argentino de Internet de las Cosas
48JAIIO - TAIC - ISSN: 2683-8982 - Página 12


Spanish

Sistema de monitoreo remoto versátil para riego por pivote central

SEDICI - Repositorio de la UNLP

Servicio de Difusión de la Creación Intelectual

Sistema de monitoreo remoto versátil para riego porpivote centralIñaki Albisu1, Juan Pablo Araneta12, Federico Cisneros1, José Mariano Finochiet-to123, Juan Manuel Garin1 y José Robetto121 PONCE, Mar del Plata 7600, Argentina{i.albisu, j.araneta, m.finochietto, j.robetto}@ponceautomations.com2 Universidad CAECE, Mar del Plata 7600, Argentina3 GIDI, Departamento de Informática, Universidad Nacional de Mar del Plata,Mar del Plata 7600, Argentinamariano.fino@fi.mdp.edu.arPalabras Claves: Internet de las Cosas, agricultura sustentable1   IntroducciónUno de los sistemas de riego que más creció en superficie regada en la última dé-cada en Argentina es el pivote central [1]. Este sistema de riego por aspersión estáconformado por una pirámide  en el  centro,  y una serie  de tramos enlazados  quegiran alrededor de la misma esparciendo agua y formando un círculo. Los caudalesde agua utilizados varían según el cultivo y la configuración del equipo, pero es co -mún que alcancen los 120.000 lt/h o más. Al ser equipos que operan de manera au -tónoma por varios días, no requieren de personas en el lote. Sin embargo, se realizanrondas de supervisión diarias ya que cualquier desperfecto en el equipo puede re -sultar en grandes pérdidas. Por ejemplo, si el equipo no avanza porque sus ruedaspatinan en el barro y la bomba sigue funcionando con un caudal como el descrito, seestarían desperdiciando miles litros de agua dulce por hora que podrían utilizarsepara otros consumos.Existen  alternativas  a  las  rondas de  supervisión  para  conocer  el  estado  de losequipos sin tener que viajar al campo, pero tienen dos características que dificultanla adopción por parte de los productores. La primera es que dependen de una infra -estructura de comunicación que en muchas zonas de Argentina no está disponible[2]. Estas necesitan de cobertura celular o WiFi en el lote o en las proximidades delmismo, ya sea para enviar alertas SMS, para comunicarse desde el lote a un servidoren Internet, o para comunicarse con un nodo cercano mediante RF y utilizarlo comogateway a Internet. La segunda es que muchos de estos productos son provistos porlos mismos fabricantes de equipos de riego y sólo funcionan en algunos modelos.Este trabajo presenta el diseño e implementación de un sistema de Internet de lasCosas  [3]  que  permite  monitorear  el  estado  de  un  pivote  central.  Se  adapta  acualquier modelo, y puede instalarse en cualquier lote de Argentina.TAIC, Taller Argentino de Internet de las Cosas48JAIIO - TAIC - ISSN: 2683-8982 - Página 92   Materiales y métodosEl sistema  puede organizarse  mediante  las  cinco  capas  arquitectónicas  [3]  co-múnmente utilizadas para estructurar un sistema de Internet  de las Cosas: percep -ción,  transporte,  procesamiento,  aplicación  y negocio.  Para simplificar  el  análisisdel diseño del sistema, no se incluye la capa de negocios y algunos servicios (comolas notificaciones SMS), y tampoco se detallan los algoritmos de detección de fallas.La Figura 1 muestra los componentes principales,  y a continuación se describen lascapas.Fig. 1. Diagrama de capas de la solución con orientación horizontala) Capa percepción: El desafío principal en esta capa es el de diseñar un sistemade  sensores  que  pueda  ser  utilizado  en  cualquier  pivote  central  (interoperable).Luego de analizar productos similares [4], se determinó utilizar un receptor GPS enla punta de los tramos y un sensor de presión en el caño principal de agua del equi -po. El receptor GPS es la placa open source SODAQ ONE v3 [5] alimentado con unpanel solar de 1 WATT, el cuál envía la posición periódicamente a un gateway dise -ñado especialmente para este proyecto. El gateway se alimenta del tablero principaldel pivote, y tiene conectado el sensor de presión a una entrada analogica de su mi-crocontrolador ATMEGA2560. Con la posición se determina su ubicación y si seestá moviendo, y con el sensor de presión si hay agua fluyendo.b) Capa transporte: Dos puntos importantes  a  resolver  en esta  capa  incluyencómo comunicar el receptor GPS con el gateway, teniendo en cuenta que puede ha-ber cientos de metros de distancia entre ambos, y cómo enviar los datos del campo aun servicio remoto, considerando que el lote puede no contar con señal celular niservicio de Internet. Para el primer caso, se resolvió utilizar LoRa, un protocolo RFque tiene un alcance teórico mayor a 30 km [6]. Para el segundo caso, se escogió lacomunicación satelital ya que esta garantiza conectividad en cualquier ubicación acielo abierto sin necesidad de montar una infraestructura aparte. El proveedor elegi-do fue SkyWave que cuenta con una red de satélites geoestacionarios llamada Isat -TAIC, Taller Argentino de Internet de las Cosas48JAIIO - TAIC - ISSN: 2683-8982 - Página 10Data Pro (IDP) con cobertura en la región. El gateway, entonces, arma un paquetecon datos de presión y posición, y los envía al satélite cada 15 minutos, para queluego sean consumidos por una interfaz REST. El período de envío se eligió consi-derando los costos del servicio satelital y la necesidad de negocio.c) Capa procesamiento: El objetivo de esta  capa es procesar  y almacenar  losdatos que llegan desde el campo, para determinar si el equipo de riego está apagado,regando o en falla. Al estar en una fase experimental, es importante poder aumentaro disminuir fácilmente los recursos necesarios para el procesamiento. Se optó pormontar un ambiente  serverless, en el cuál el proveedor asigna los recursos necesa-rios para ejecutar el código de manera dinámica [7]. Puntualmente se eligió un mo-delo FaaS (Function-as-a-Service), donde el código que se envía al servidor es unafunción asociada con un activador. Como proveedor, se optó por Google Cloud Plat -form, debido a que ya se contaba con experiencia en su uso, y los productos utili -zados fueron Cloud Functions como herramienta FaaS y Cloud PubSub como sis-tema de mensajería y activadores. Para almacenar tanto los paquetes sin procesar (amodo de copia de seguridad) y los estados ya procesados, se eligió  Keen.io que esun servicio robusto de almacenamiento y consulta de eventos, el cual permite  aso-ciar  dichos datos  con una  fecha  y hora  para  optimizar  consultas  con parámetrostemporales.d) Capa aplicación: Se relevaron cuatro requerimientos que se destacan. El pri-mero es que se debe poder acceder desde un teléfono celular ya que el productor ag -rícola no siempre está en su oficina. El segundo involucra la interoperabilidad por loque debe funcionar en gran variedad de modelos y marcas de celular (smartphones).El tercero es que la interfaz gráfica debe reflejar rápidamente los cambios de estadodel  riego  de  manera  automática.  Y el  cuarto  es  que  se  debe  poder  consultar  lainformación aún cuando no haya conexión a Internet, por ejemplo en el campo. Pararesolver  las primeras dos cuestiones se desarrolló una aplicación web adaptable adistintos  tamaños  de  pantalla,  lo  que  permite  utilizar  cualquier  celular  modernocomo cliente.  Para las otras dos, se utilizó la base de datos NoSQL Firestore, quemediante WebSockets actualiza a los clientes cuando detecta un cambio en sus do-cumentos,  y  se  optó  por  desarrollar  la  aplicación  como PWA (Progressive  WebApplications) con caché en el cliente.3   ResultadosLa Figura 2 muestra imágenes de los resultados del diseño e implementación delsistema propuesto, que comenzó en mayo de 2018 y culminó en marzo de 2019. Entotal,  se  monitorearon  59  equipos  de  5  marcas  distintas:  Valley,  Lindsay,  T-L,Montenegro y Rockink. La distancia más larga entre el receptor GPS y el gatewayfue de 770 m mientras que la más corta fue de 282 m. Los mismos estuvieron distri -buidos en la Provincia de Buenos Aires, procesando más de 8.035.200 bytes prove-nientes del gateway y detectando 144 fallas verificadas por los usuarios.TAIC, Taller Argentino de Internet de las Cosas48JAIIO - TAIC - ISSN: 2683-8982 - Página 11(a) (b) (c) (d)Fig. 2. Implementación del sistema: (a) foto del gateway en campo, (b) foto de laplaca del gateway, (c) foto del receptor GPS en campo y (d) captura de la aplicación4   ConclusionesSe presentó una propuesta de sistema de Internet  de las Cosas y su implemen -tación, aplicada a una problemática del agro. Entre los desafíos futuros se encuen-tran monitorear nuevos modelos de pivote en nuevas regiones del país y mejorar lacalidad del servicio en base al análisis de los datos recolectados en esta experiencia.Además, se trabajará en cómo utilizar los datos disponibles para agregar más funcio-nalidad y en incorporar nuevos sensores migrando a un estándar como LoRaWAN.Referencias1. UTF/ARG/017/ARG Desarrollo Institucional para la Inversión: Estudio del potencial deampliación del riego en Argentina. FAO. ISBN 9789253089956. (2015)2. ENACOM. Mapa de conectividad nacional.  https://indicadores.enacom.gob.ar/MapasCo-nectividad.aspx3. Sethi, Pallavi, and Smruti R. Sarangi. Internet of Things: Architectures, Protocols, andApplications. Journal of Electrical and Computer Engineering 2017 (2017) 1-254. Peters, R. T., and S. R. Evett. Using Low-Cost Gps Receivers For Determining FieldPosition Of Mechanized Irrigation Systems. Applied Engineering in Agriculture 21, no. 5(2005) 841-455. SODAQ ONE. 10/7/2019, de SODAQ. https://support.sodaq.com/sodaq-one/sodaq-on6. Ray, Partha Pratim. Internet of Things for Smart Agriculture: Technologies, Practices andFuture  Direction.  Journal  of  Ambient  Intelligence  and  Smart  Environments  9,  no.  4(2017) 395-4207. Eyk,  Erwin Van, Lucian Toader,  Sacheendra  Talluri,  Laurens  Versluis,  Alexandru Uta,and Alexandru Iosup. Serverless Is More: From PaaS to Present Cloud Computing. IEEEInternet Computing 22, no. 5 (2018) 8-17TAIC, Taller Argentino de Internet de las Cosas48JAIIO - TAIC - ISSN: 2683-8982 - Página 12

http://sedici.unlp.edu.ar/bitstream/handle/10915/89261/Documento_completo.pdf?sequence=1

Een archeologisch bureau-onderzoek voor de locatie Wooldstraat 33 te Winterswijk (Gld)

Abstract

Similar works

Full text

Available Versions

Electronic Archiving System

El Servicio de Difusión de la Creación Intelectual

SEDICI - Repositorio de la UNLP

Servicio de Difusión de la Creación Intelectual