Tecnico2026-10-06
Una migración de sistema de riego inteligente tiene éxito cuando la nueva plataforma conserva los futuros riegos previstos por la explotación y asume el control mediante una entrega verificada. Copiar nombres de estaciones y duraciones es solo parte del trabajo. Las fechas de referencia de los intervalos, las suspensiones temporales, las asignaciones de dispositivos y el registro de riegos ya completados pueden cambiar lo que ocurre después de importar.
Conexiones rectas negras para tuberías de riego. La fotografía muestra componentes físicos, no una migración de plataforma ni un programa importado. Foto: IrriNex.
Esta guía desarrolla un inventario de migración, una comparación de calendarios y un registro del cambio para riego agrícola. Los ejemplos son hipotéticos. Utilice las capacidades documentadas de ambos sistemas y el plan operativo aprobado de la explotación; un archivo transferible no demuestra compatibilidad eléctrica ni un comportamiento de riego equivalente.
Enumere los campos, controladores, programas y equipos compartidos incluidos. Un cambio de servicio en la nube puede conservar el controlador de campo, mientras que sustituir el controlador puede cambiar sus salidas y su motor local de programación. Son alcances distintos, aunque después los operadores utilicen la misma aplicación del teléfono.
Asigne una persona para aprobar cambios durante la migración y otra para confirmar las condiciones en campo. Elija un periodo que considere las necesidades del cultivo, la disponibilidad de agua y el apoyo cualificado. Congelar la configuración debe impedir cambios sin registrar, pero no evitar que un operador responda a un problema real. Cualquier cambio necesario se convierte en una actualización registrada de la referencia de migración.
Antes de programar el trabajo, confirme por separado la interfaz física con la guía de controladores de riego AC, DC y con decodificadores. Una cantidad de estaciones coincidente no demuestra que el sustituto pueda accionar las válvulas instaladas. Si hace falta cambiar cableado, personal cualificado debe seguir los procedimientos aprobados del equipo.
Establezca de antemano una condición práctica para detener el proceso: por ejemplo, una asignación de campo sin resolver, una regla de programación no compatible o la imposibilidad de establecer una sola autoridad de mando impide liberar esa parte de la migración. Una bomba compartida puede exigir mantener en espera un grupo mayor de zonas. Termine de definir ese alcance antes de confiar en el porcentaje de progreso de la herramienta de importación.
Guarde una exportación identificable y fechada de la configuración anterior y un registro accesible, legible para una persona, de sus ajustes importantes. Anote las versiones de software y controlador, la hora de exportación y quién confirmó la referencia. Preserve la exportación original para que las correcciones posteriores no eliminen la prueba de lo transferido.
El inventario siguiente distingue información que puede parecer similar en dos interfaces y producir un resultado diferente en campo. En cada fila, registre el valor anterior, el de destino, cualquier transformación aprobada y las pruebas utilizadas para aceptar el resultado.
| Elemento de migración | Qué conservar o resolver expresamente | Pruebas útiles para comparar |
|---|---|---|
| Programas y reglas del calendario | Estado habilitado, horas de inicio, días activos, fecha de referencia y excepciones | Listas de eventos futuros generadas para las mismas fechas y base horaria |
| Asignaciones de zonas y salidas | Campo físico, identidad del controlador, salida de estación y dependencias compartidas | Mapa de campo aprobado contrastado con las asignaciones de destino |
| Interpretación de las duraciones | Duraciones base, ajustes activos, reglas de ciclos y límites | Secuencia propuesta de estaciones, incluidas pausas y transiciones |
| Estado operativo temporal | Suspensiones activas, condiciones de vencimiento, trabajo incompleto y solicitudes en cola | Registro del estado inmediatamente antes del traspaso de autoridad |
| Sensores y cálculos | Identidad, ubicación, unidades, interpretación de calibración y reglas habilitadas | Lecturas y cálculos seleccionados comprobados con sus metadatos |
| Historial y notificaciones | Eventos completados, lagunas conocidas, cambios de operadores y destinatarios de alarmas | Muestras históricas legibles y una prueba de notificación permitida |
Un coeficiente de calibración debe transferirse solo con su definición y un cálculo cuya compatibilidad esté confirmada. El destino puede esperar otra ecuación, unidad o salida del sensor. Conserve el registro anterior aunque no pueda importarlo directamente y resuelva la conversión antes de habilitar una regla de riego dependiente del sensor. La guía de ubicación de sensores de humedad del suelo explica la importancia del lugar asociado a una lectura.
Separe los registros históricos de las solicitudes ejecutables. Importar un riego anterior en una tabla de historial no debe crear una nueva tarea de riego. Si el destino combina esas funciones o no documenta la diferencia, solicite un método de migración demostrado antes de utilizar la importación con equipos operativos.
Considere un programa ficticio que empieza a las 05:30 UTC cada dos días, tomando el 5 de octubre de 2026 como referencia. La migración está prevista para el 6 de octubre a las 12:00 UTC, y el riego del 5 de octubre ya terminó. Todas las horas del ejemplo utilizan UTC, por lo que los cambios estacionales de hora quedan fuera del cálculo.
Si una importación reinicia la referencia en el 6 de octubre, el intervalo y la hora pueden parecer correctos mientras cambian todas las fechas generadas. La tabla compara las reglas del calendario, incluidas fechas anteriores al cambio propuesto. Es una comparación sin funcionamiento físico, no una instrucción para ejecutar ninguno de los programas.
| Regla del calendario comparada | Inicios generados a las 05:30 UTC | Primer inicio después del 6 de octubre a las 12:00 UTC |
|---|---|---|
| Original: intervalo de dos días referido al 5 de octubre | 5, 7, 9 y 11 de octubre | 7 de octubre |
| Importación incorrecta: mismo intervalo referido al 6 de octubre | 6, 8, 10 y 12 de octubre | 8 de octubre |
| Importación corregida: referencia original conservada | 5, 7, 9 y 11 de octubre | 7 de octubre |
La importación incorrecta retrasa un día el siguiente evento previsto en este ejemplo. Su inicio del 6 de octubre ya está en el pasado al efectuar el cambio. Que el software ignore ese evento o intente recuperarlo es un comportamiento independiente que debe establecerse; una marca temporal pasada no da permiso para regar inmediatamente.
La especificación iCalendar del IETF, RFC 5545, considera el inicio inicial y la regla de recurrencia como partes del conjunto de eventos generado, con exclusiones que afectan al resultado. Este principio del calendario explica por qué un intervalo aislado es insuficiente. No significa que una plataforma de riego admita importaciones iCalendar o implemente todas las reglas del RFC.
En la explotación real, compare un horizonte suficientemente largo para incluir cada regla relevante: límites de intervalos, restricciones por día de la semana, cambios de mes y excepciones activas. Si utiliza hora civil local, examine también cualquier cambio de hora aplicable. Registre qué debe ocurrir cuando una hora local falta o se repite; no suponga que ambos motores lo resuelven igual.
Un programa puede conservar sus fechas y aun así cambiar el agua distribuida si el destino interpreta la duración de otra manera. Determine si la duración exportada es el valor base original o un resultado ya ajustado. Volver a aplicar un ajuste sobre una duración ajustada cambia el funcionamiento propuesto. Compare la secuencia final de estaciones con la referencia aprobada antes de habilitar la ejecución automática.
Registre qué dispositivo toma actualmente cada decisión. El software meteorológico puede proponer una duración mientras el controlador de campo aplica una suspensión local. Una migración que copie solo el programa de la nube puede omitirla. Conserve su alcance y condición de vencimiento, o documente un equivalente aprobado cuando el destino no pueda representarla directamente.
Compruebe las dependencias a ambos lados de la migración. Una zona trasladada al nuevo servicio puede seguir compartiendo una bomba con zonas del servicio anterior. La guía de enclavamientos de automatización del riego aporta el contexto operativo de bombas y válvulas. Mantenga las protecciones aprobadas durante el cambio; importar datos correctamente no valida una nueva secuencia de bombeo.
Cuando una regla no sea compatible, manténgala como elemento de migración sin resolver, con un responsable y una decisión. Las opciones pueden incluir un equivalente documentado, un rediseño cualificado o conservar esa parte en su sistema anterior. Omitir silenciosamente una excepción hace que el destino parezca más sencillo, pero modifica la operación prevista por el agricultor.
Utilice una vista previa sin operación, un simulador o una disposición documentada de solo observación para comparar el destino con el sistema anterior. Solo el sistema activo aprobado debe poder emitir órdenes operativas al equipo migrado. Dos paneles que muestran el mismo campo no demuestran que los canales de mando estén separados.
Incluya los programas locales, los trabajos en la nube, los servicios conectados y las aplicaciones de los operadores. Cerrar sesión en una aplicación no demuestra que su controlador o servicio haya dejado de programar. La guía de riego inteligente con Internet poco fiable explica la importancia del funcionamiento local cuando falta la conexión.
La guía de contingencia NIST SP 800-34, revisión 1, de 2010 distingue la validación de los datos recuperados, la de las funciones y el regreso documentado al funcionamiento normal. Estos principios de recuperación informática orientan el registro de entrega aquí propuesto. Su explicación del procesamiento concurrente no autoriza a dos sistemas de riego a controlar simultáneamente el mismo equipo de campo.
Defina el traspaso de autoridad como un evento observable. Use los procedimientos documentados para establecer la liberación del sistema anterior y la aceptación del destino, con confirmación de campo apropiada. Si no puede establecer esa separación, mantenga inactivo el destino y resuelva la disposición de control antes de continuar.
El registro final de entrega une la configuración con lo que realmente ocurrió. Termine o resuelva expresamente cualquier riego en marcha utilizando la secuencia operativa aprobada. Concilie las solicitudes de resultado incierto antes de recrearlas en otro lugar. Una copia de configuración no indica si una solicitud tardía se ejecutó después de realizar la copia.
| Registro del cambio | Pruebas que conservar | Pregunta para autorizar |
|---|---|---|
| Referencia y cambios posteriores | Exportación fechada y cada cambio aprobado realizado después | ¿Representa el destino la última configuración aprobada? |
| Último riego confirmado | Campo, hora del evento, prueba de finalización y cualquier resultado incierto | ¿Podría una solicitud importada o en cola repetir agua ya distribuida? |
| Traspaso de autoridad | Estado del antiguo canal de mando y del destino, hora y operador responsable | ¿Está operativa únicamente la autoridad prevista? |
| Siguiente riego permitido | Programa, campo, fecha, base horaria y suspensiones o condiciones aplicables | ¿Coincide el siguiente evento con el calendario futuro aprobado? |
| Observación y aceptación | Primera operación permitida, revisiones de campo, cuestiones abiertas y alcance aceptado | ¿Qué pruebas respaldan autorizar este grupo de equipos? |
En el ejemplo del calendario, el registro identificaría el evento completado del 5 de octubre y el previsto del 7 de octubre, siempre que ninguna otra condición impida ese inicio. Migrar no crea un derecho adicional a regar entre ellos. Sigue siendo posible un cambio agronómico aprobado por el operador, pero debe registrarse como una decisión nueva.
Conserve el historial anterior en una forma utilizable de solo lectura cuando sea compatible. Compruebe que los operadores distinguen los registros previos a la migración de los del destino e identifican cualquier laguna en la frontera. Mantenga acceso durante el periodo de conciliación acordado; eliminar la cuenta anterior demasiado pronto puede hacer imposible investigar una discrepancia aparente.
Defina los motivos para volver atrás y la persona responsable antes del cambio. Restaurar una configuración anterior no puede revertir agua ya aplicada al campo. Concilie los eventos completados, incompletos e inciertos antes de establecer la siguiente operación permitida del sistema anterior.
Por ejemplo, si la nueva plataforma ya completó el evento del 7 de octubre, restaurar una copia del 6 de octubre no justifica ejecutar otra vez el del 7 de octubre. El equipo necesita un registro operativo actualizado y una sola autoridad verificada, no simplemente un mensaje de restauración correcta. Cualquier nueva necesidad de riego debe seguir la evaluación actual de la explotación.
Tras aceptar el sistema, guarde una nueva referencia del destino y conserve el registro de migración, las limitaciones conocidas y las instrucciones de recuperación. Cierre accesos temporales y canales redundantes de mando mediante el procedimiento de entrega aprobado. El resultado útil es un estado operativo comprensible que el turno siguiente pueda gestionar sin reconstruir de memoria la migración.
Solo si el destino documenta la importación pertinente y su significado. Una hoja puede transferir valores y perder una fecha de referencia, un estado deshabilitado, una excepción o una relación con equipos compartidos. Compare los eventos futuros generados y el comportamiento final antes de aceptar el programa importado.
Pueden compararse mediante una disposición aprobada sin operación o de solo observación. Establezca una sola autoridad activa de mando por grupo de equipos migrado, incluidos programas locales y servicios conectados. No use órdenes simultáneas de riego como método de comparación.
No. Restaurar una configuración no deshace el agua distribuida, no revierte una operación de válvula completada ni explica una solicitud incierta. Concilie el registro, evalúe las condiciones actuales y confirme el siguiente riego permitido antes de autorizar el sistema restaurado.
Productos relevantes para esta guía de riego.
Aspersor tipo cañón de lluvia IRRINEX. Tamaño de conexión: G25inch(63mm); diámetro de boquilla: 20X7.5mm; presión: 0.4-0.5mpa; radio: 35-45m. Un cañón de lluvia es un componente de aspersión seleccionado para un diseño de riego definido. La boquilla, la conexión y las condiciones de funcionamiento deben comprobarse conjuntamente para el modelo elegido.
Bandeja de propagación de plántulas IRRINEX. Tamaño: 540*280mm; Espesor: 0.8mm; Alvéolos: 21/28/32/50/72/98/105/128/200. Una bandeja de plántulas organiza la propagación en alvéolos de plantación separados. Deben comprobarse el número de alvéolos, las dimensiones de la bandeja y el material para la configuración seleccionada.
Manguera o cinta de riego por aspersión IRRINEX. Diámetro: 16mm-125mm; Espesor de pared: 0.15mm 0.2mm 0.3mm 0.4mm....; Separación entre goteros: 20cm; Diámetro aplanado: N25mm. La manguera o cinta de aspersión es un componente de riego distribuido para un diseño de plantación seleccionado. Use las dimensiones y la información de funcionamiento indicadas para la configuración exacta.
Temporizador o programador de riego IRRINEX. Accionamiento: solenoide; intervalo de medición: 1-8bar. Un temporizador o programador de riego proporciona funciones de control para la disposición de riego seleccionada. Compruebe su conexión real, alimentación y configuración de control, sin asumir que todos los productos tienen las mismas funciones.