Actualización sobre la Causa Raíz y Prevención de Incidentes Similares

Última actualización: 15:05 CET 12.08.2025

Declaración del Responsable del Departamento Técnico en Nofence

Hola, mi nombre es Egil Anonsen, y soy el responsable del departamento técnico aquí en Nofence.

Quería darles más información sobre el reciente incidente que ocurrió la semana pasada. Lo haré enfocándome en tres áreas principales:

• Primero, pasaré por la cronología y la secuencia de los eventos.

• En segundo lugar, proporcionaré información sobre nuestra comprensión actual del problema y la hipótesis sobre la causa raíz de este incidente.

• Y finalmente, miraremos hacia el futuro y daré algunas ideas sobre lo que podemos hacer para evitar que esto vuelva a ocurrir.

Cronología y secuencia de eventos

Déjenme comenzar con la cronología y lo que realmente sucedió.

El fin de semana pasado vimos un leve aumento en los pulsos en ciertos collares, concretamente la versión 2.2 y versiones anteriores, lo que típicamente llamamos dispositivos Legacy, en nuestros sistemas internos de monitoreo, y también un aumento en los tickets de soporte. Contamos con un monitoreo integral y alertas automáticas para nuestra flota, con ingenieros que están de guardia y son notificados fuera del horario laboral y durante el fin de semana.

El lunes por la mañana, 4 de agosto, quedó claro que esto era más que algunos incidentes aislados, y que estaba afectando a una parte más grande de nuestra flota. En cuanto entendimos que se trataba de un incidente importante, seguimos nuestro procedimiento interno de escalado y reunimos todos los recursos disponibles en un grupo de trabajo. Desde entonces, el grupo de trabajo ha trabajado día y noche tratando de entender el problema, con la máxima prioridad de mitigar los pulsos excesivos lo antes posible.

Como parte del proceso de escalado, informamos a los clientes el mismo día de que deberían considerar ampliar el pasto, evitar vallados cercanos a edificios o incluso eliminar el vallado si fuera posible para los collares afectados.

Pronto quedó claro que solo estaba afectando a los collares de las versiones 2.2 y anteriores, que son los collares vendidos hasta principios de 2023. También fue claro que tanto los collares para ganado como para ovejas/cabra se veían afectados de manera similar, y también afectó a los collares en todos los mercados geográficos. Sin embargo, la gran mayoría estaba en Noruega, simplemente porque ahí es donde vendimos la mayoría de nuestros collares hasta 2023.

Estimamos que aproximadamente el 5% de nuestra flota de collares se vio afectada por este incidente.

También me gustaría mencionar que la gran mayoría de nuestra flota está compuesta por la versión 2.5, que comenzó a enviarse en 2023, y estos collares no se vieron afectados por este incidente.

Todos nuestros collares son actualizables de forma remota, tanto los collares 2.2 y anteriores, como la versión más reciente 2.5. El martes 5 de agosto, después de un análisis y pruebas adicionales, desplegamos dos nuevas configuraciones a la flota, incluyendo deshabilitar el modo de ahorro de energía, sin embargo, ninguna de ellas tuvo el efecto deseado.

Finalmente, el miércoles 6 de agosto, desplegamos otra configuración alrededor de las 14:00 a las 20:00 en el 20% de la flota afectada. Vimos rápidamente una mejora significativa y luego decidimos desplegar esta configuración a toda la flota. Poco después de esto, vimos que todos los collares comenzaron a recuperar su funcionamiento, y el número de pulsos volvió a los niveles anteriores al incidente.

Por precaución, queríamos ver 24 horas de operación estable antes de informar a los clientes que ahora era seguro usar los collares nuevamente. Como resultado, comunicamos esto más tarde el jueves, después de 24 horas de actividad normal de los collares.

En los últimos días, también hemos vuelto a habilitar el modo de ahorro de energía en todos los collares, por lo que ahora los collares deberían comportarse tan bien como lo hacían antes del incidente.

Hipótesis sobre la causa raíz

Ahora hablaré sobre nuestra comprensión actual de la causa raíz, aunque es importante decir que aún no lo entendemos completamente y seguimos trabajando diligentemente para llegar al fondo de esto.

La versión 2.2 de los collares se basa en un diseño de hace varios años, por lo que utiliza tecnología y electrónica que desde entonces ha mejorado. La versión 2.2 utiliza un receptor de Sistema Global de Navegación por Satélite (GNSS), conocido como receptor Zoe M8, fabricado por uBlox, uno de los mayores fabricantes de GNSS del mundo. Pero este receptor GNSS, llamado Zoe M8, tiene algunas debilidades y limitaciones. Desde entonces, lanzamos la nueva versión 2.5 de nuestro collar, que utiliza el nuevo y mejorado receptor GNSS llamado MIA M10.

Existen 4 principales constelaciones GNSS en uso hoy en día: GPS, Galileo, GLONASS y Beidou. El Zoe M8 tiene algunas limitaciones que hacen que solo sea capaz de rastrear dos de estas constelaciones simultáneamente, a la vez que lo hace con bajo consumo de energía. Desarrollar un producto como un collar de vallado virtual es un ejercicio continuo para equilibrar los diferentes parámetros y hacer el mejor producto en general. Por lo tanto, los collares 2.2 utilizan las constelaciones GPS y Glonass como un compromiso entre la precisión de la ubicación y el consumo de energía.

Normalmente, estos collares ven alrededor de 16 satélites, lo que en la mayoría de los casos da una posición muy fiable. Sin embargo, durante el incidente, vimos que esto bajaba a alrededor de 11-12 satélites. Cuando el collar ve menos satélites, normalmente experimenta una posición menos fiable. Esto puede hacer que la posición GNSS se desplace, haciendo que el collar piense que el animal está fuera del vallado cuando en realidad no lo está, y luego inicie incorrectamente la secuencia de corrección con audio y pulsos.

Los collares 2.2 también utilizan una característica llamada AssistNow Offline (también conocida como ANO), que es útil después de que el collar ha estado en modo de ahorro de energía, el cual se activa cuando el animal no se mueve mucho, para extender la vida útil de la batería del collar. Cuando el animal se despierta y comienza a moverse de nuevo, el receptor GNSS se vuelve a encender, y ANO ayuda a predecir dónde estarán los satélites GPS. Como resultado, el collar debería obtener una posición fiable más rápido al salir del modo de ahorro de energía en lugar de empezar desde cero. Esta duración también se conoce como el tiempo hasta el primer arreglo, o TTFF.

Como mencioné anteriormente, Glonass es una de las constelaciones utilizadas por los collares legacy. La constelación de Glonass puso un satélite en mantenimiento que coincide bien con el momento en el que ocurrió el incidente. Actualmente creemos que el ZOE-M8 no manejó correctamente este evento y perdió su capacidad para rastrear todos los satélites disponibles, por lo que su capacidad para dar una ubicación precisa se redujo.

En comparación, el collar versión 2.5, que tiene un receptor de última generación, utiliza tanto GPS, Galileo como Beidou simultáneamente, y típicamente ve alrededor de 25 satélites. Esto significa que es mucho más resistente a tales disturbios GNSS como el que acabamos de experimentar.

La solución desplegada el miércoles pasado consistió en deshabilitar esta función ANO para nuestros collares. Esto significa que los collares no descargarán un archivo con predicciones de dónde estarán los satélites, sino que obtendrán esta información directamente de los satélites durante la operación normal. Hemos visto que, según un análisis temprano de la flota durante el fin de semana, este cambio pudo haber reducido el TTFF en la mayoría de los escenarios, lo que significa que el collar debería comportarse actualmente tan bien como lo hacía antes del incidente.

Cómo evitar que esto suceda en el futuro

Finalmente, ahora que el incidente ha sido mitigado, el enfoque se centra en entender adecuadamente la causa raíz e implementar acciones mitigadoras para reducir la probabilidad de que un incidente similar ocurra nuevamente. También estamos trabajando estrechamente con nuestro proveedor de GNSS uBlox para investigar esta cuestión y aplicar las acciones correctivas más efectivas. Esta es la pista más importante, porque para encontrar las mejoras más fiables y efectivas que implementar en el futuro, necesitamos entender completamente qué salió mal.

Es importante decir que ya tenemos algoritmos funcionando en el collar para manejar las perturbaciones GNSS y evitar que el animal reciba pulsos no deseados. No debemos simplemente aceptar que menos satélites resulten en más pulsos no deseados, pero este incidente ha dejado claro que estos algoritmos necesitan mejorar aún más.

Además de reportar la posición cada 15 minutos, los collares también informan de muchos metadatos que usamos para entrenar y mejorar nuestros algoritmos. Ahora estamos investigando qué parámetros y algoritmos podemos usar para detectar tales perturbaciones GNSS y manejarlas de manera más eficiente para evitar estos pulsos no deseados. Un ejemplo podría ser hacer más suposiciones sobre el comportamiento del animal y cómo se mueve, y si de repente la posición está muy fuera del cercado, concluir que lo más probable es que sea una perturbación GNSS y filtrar esa posición.

También estamos explorando el uso de diferentes constelaciones GNSS, aunque algunas de estas tendrán un consumo de energía significativamente mayor. Estas configuraciones luego podrían desplegarse rápidamente a nuestra flota como una solución temporal mitigadora si un incidente similar ocurriese en el futuro.

También estamos considerando exponer más configuraciones al usuario final si se vuelve a producir un incidente similar, como deshabilitar potencialmente el pulso mientras mantenemos la advertencia de audio de forma individual por collar, pero los detalles de esto aún están siendo trabajados.

Por supuesto, también revisaremos nuestras métricas internas y sistemas de alertas para asegurarnos de que un incidente similar sea detectado lo antes posible, de modo que la información pueda ser dada rápidamente y podamos realizar acciones mitigadoras en la flota para minimizar el impacto general.

Finalmente, me gustaría expresar nuevamente nuestras más sinceras disculpas por este incidente, y haremos todo lo que podamos para asegurarnos de que esto no vuelva a ocurrir.

Gracias.