ES2969966T3 - Marco modelo de desarrollo para un mantenimiento basado en la condición de monitorización remota - Google Patents

Abstract

Las realizaciones incluyen técnicas para desarrollar un marco modelo para el mantenimiento basado en la condición de monitoreo remoto de unidades. Las técnicas incluyen la recopilación de datos asociados con solicitudes de servicios no planificadas y la generación de uno o más modelos a partir de los datos recopilados. Las técnicas también incluyen predecir solicitudes de servicio no planificadas basándose al menos en parte en uno o más modelos, y transmitir una salida de la predicción de la solicitud de servicio no planificada. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Marco modelo de desarrollo para un mantenimiento basado en la condición de monitorización remota Antecedentes

Las realizaciones en la presente memoria se relacionan con sistemas de modelado, y más específicamente, con el desarrollo de un marco modelo para una unidad remota que monitorice el mantenimiento basado en la condición.

Muchos sistemas complejos como sistemas de ascensor y sistemas de escaleras mecánicas recopilan datos para monitorizar el rendimiento del sistema durante un período de tiempo. Estos datos pueden recopilarse, manualmente, de los mecánicos de servicio o de otras fuentes, como sensores que están configurados para leer diversos datos operativos o de alarma de los sistemas. Además, algunos datos pueden ser proporcionados por otros sistemas externos o de terceros que proporcionan servicios de monitorización. Puede haber una oportunidad de aprovechar los datos recopilados para realizar análisis predictivos y de diagnóstico para reducir los fallos y el tiempo de inactividad asociados al sistema. Los documentos EP 3587326 y EP 3456673 se presentaron antes y se publicaron después de la fecha de prioridad de la solicitud actual. El documento EP 3587326 describe un sistema para programar un mantenimiento en función de datos de monitorización remota y análisis de los datos de servicio. El documento EP 3456673 describe un sistema de monitorización de la condición para realizar una transformación de datos mixtos de ascensores. El documento CN 105731209 describe un sistema de Internet de las Cosas para diagnóstico y mantenimiento de un sistema de ascensor. El documento CN 107826919 describe un dispositivo de monitorización para un sistema de elevación.

Breve compendio

Según una realización, se proporciona un sistema para desarrollar un marco modelo para una unidad remota que monitorice el mantenimiento basado en la condición, como se reivindica en la reivindicación 1.

Otras realizaciones utilizan los datos que incluyen, al menos, uno de datos de la unidad, datos de rendimiento, o registros de servicio.

Otras realizaciones utilizan datos que incluyen, al menos, dos de los datos de la unidad, datos de rendimiento, o registros de servicio.

Otras realizaciones incluyen el uso de datos de la unidad, datos de rendimiento, y registros de servicio. Otras realizaciones incluyen, al menos, una de una unidad de ascensor o una unidad de escalera mecánica. Otras realizaciones incluyen modelos que se generan utilizando un proceso de aprendizaje automático supervisado.

Otras realizaciones incluyen generar más de un modelo en función de la generación de una puntuación de salud para la unidad.

Otras realizaciones incluyen un procesador que se configura para seleccionar un modelo de más de un modelo, y probar el modelo seleccionado en función de un conjunto de datos independiente de los datos recopilados. Otras realizaciones incluyen proporcionar una salida que incluya, al menos, una de un ID de unidad, una puntuación estimada relacionada con la probabilidad de una solicitud de solicitud de servicio, y una o más características que contribuyeron a la puntuación estimada.

Otras realizaciones incluyen proporcionar una salida de más de un modelo para actualizar un programa de mantenimiento.

Según una realización diferente, se proporciona un método para desarrollar un marco modelo para una unidad remota que monitorice el mantenimiento basado en la condición, como se reivindica en la reivindicación 9. Otras realizaciones utilizan datos que incluyen, al menos, uno de datos de la unidad, datos de rendimiento, o registros de servicio.

Otras realizaciones utilizan datos que incluyen, al menos, dos de los datos de la unidad, datos de rendimiento, o registros de servicio.

Otras realizaciones utilizan datos que incluyen datos de la unidad, datos de rendimiento, y registros de servicio.

Otras realizaciones incluyen, al menos, una de una unidad de ascensor o una unidad de escalera mecánica. Otras realizaciones incluyen más de un modelo que se genera utilizando un proceso de aprendizaje automático supervisado.

Otras realizaciones incluyen generar más de un modelo utilizando una puntuación de salud generada para la unidad.

Otras realizaciones incluyen seleccionar un modelo de más de un modelo, y probar el modelo seleccionado en función de un conjunto de datos independiente de los datos recopilados.

Otras realizaciones proporcionan una salida que incluye, al menos, una de un ID de unidad, una puntuación estimada relacionada con la probabilidad de una solicitud de solicitud de servicio, y una o más características que contribuyeron a la puntuación estimada.

Otras realizaciones incluyen la actualización de un programa de mantenimiento basado, al menos en parte, en la salida.

Los efectos técnicos de las realizaciones de la presente descripción incluyen predecir, estratégica y metódicamente, una devolución de llamada de un cliente aprovechando los datos que recopila el sistema. Además, la predicción puede optimizarse con el tiempo a medida que se actualizan los programas de mantenimiento y los equipos.

La siguiente descripción y dibujos tienen naturaleza ilustrativa y explicativa y no limitante.

Breve descripción de los dibujos

La presente descripción se ilustra a modo de ejemplo y no se limita en las figuras adjuntas en las que números de referencia similares indican elementos similares.

La FIG. 1 es una ilustración esquemática de un sistema de ascensor que pueden emplear diversas realizaciones de la presente descripción;

La FIG. 2 representa un sistema para poner en práctica la descripción descrita en la presente memoria; La FIG. 3 representa un sistema para desarrollar un marco modelo para un mantenimiento basado en la condición de monitorización remota; y

La FIG. 4 representa un diagrama de flujo de un método para desarrollar un marco para un mantenimiento basado en la condición de monitorización remota; y

La FIG. 5 representa un producto de programa informático de acuerdo con una o más realizaciones.

Descripción detallada

En caso de que se produzca una avería o fallo en un sistema, debe llamarse a los mecánicos de mantenimiento o de servicio para abordar el problema reportado. A continuación, debe programarse una reparación para visitar la ubicación del sistema defectuoso. En algunos escenarios, el tiempo de inactividad experimentado aumenta porque la programación del mecánico de servicio se basa en la gravedad del problema y en la disponibilidad del mecánico de servicio.

Las técnicas descritas en la presente memoria incluyen implementar un proceso dinámico de aprendizaje automático, a diferencia de las soluciones estáticas convencionales, donde se determina una ventana de tiempo en la que es probable que un cliente reporte un problema. Los modelos que se generan pueden optimizarse con datos independientes para reducir aún más el tiempo de inactividad al programar el mantenimiento antes de que expire la ventana. Una mayor optimización de los modelos puede modificar, con precisión, la ventana de una devolución de llamada de un cliente. Además, los datos pueden proporcionarse a un mecánico de servicio antes de llegar al lugar de trabajo para indicar las características principales que contribuyen a la devolución de llamada prevista. Los resultados del modelo pueden utilizarse para adaptar, estratégicamente, cómo y cuándo se realizará el mantenimiento de una o más unidades del sistema en función de la predicción de una devolución de llamada de un cliente proporcionada por el modelo.

Al realizar predicciones y decisiones basadas en datos mediante la construcción del modelo, el modelo puede optimizarse y utilizarse para ajustar los programas de mantenimiento para evitar cualquier devolución de llamada de un cliente. Por lo tanto, puede mantenerse la salud del equipo del cliente mientras que se reduce el número de devoluciones de llamadas y el tiempo de inactividad que experimenta el cliente.

Pasemos ahora a una visión general de la tecnología, la FIG. 1 es una vista en perspectiva de un sistema 101 de ascensor que incluye una cabina 103 de ascensor, un contrapeso 105, un miembro tensor 107, un carril guía 109, una máquina 111, un sistema 113 de referencia de posición, y un controlador 115. La cabina 103 de ascensor y el contrapeso 105 se conectan entre sí mediante el miembro tensor 107. El miembro tensor 107 puede incluir o configurarse como, por ejemplo, cuerdas, cables de acero, y/o correas de acero revestido. El contrapeso 105 se configura para equilibrar una carga de la cabina 103 de ascensor y se configura para facilitar el movimiento de la cabina 103 de ascensor, simultáneamente, y en una dirección opuesta con respecto al contrapeso 105 dentro de un hueco 117 de ascensor y a lo largo del carril guía 109.

El miembro tensor 107 se acopla a la máquina 111, que forma parte de una estructura aérea del sistema 101 de ascensor. La máquina 111 se configura para controlar el movimiento entre la cabina 103 de ascensor y el contrapeso 105. El sistema 113 de referencia de posición puede montarse en una pieza fija en la parte superior del hueco 117 de ascensor, como en un soporte o carril guía, y puede configurarse para proporcionar señales de posición relacionadas con una posición de la cabina 103 de ascensor dentro del hueco 117 de ascensor. En otras realizaciones, el sistema 113 de referencia de posición puede montarse, directamente, en un componente móvil de la máquina 111, o puede ubicarse en otras posiciones y/o configuraciones, como se conoce en la técnica. El sistema 113 de referencia de posición puede ser cualquier dispositivo o mecanismo para monitorizar una posición de una cabina de ascensor y/o contrapeso, como se conoce en la técnica. Por ejemplo, sin limitación, el sistema 113 de referencia de posición puede ser un codificador, un sensor, u otro sistema y puede incluir detección de velocidad, detección de posición absoluta, etc., como apreciarán los expertos en la técnica.

El controlador 115 se ubica, como se muestra, en una sala 121 de control del hueco 117 de ascensor y se configura para controlar el funcionamiento del sistema 101 de ascensor, y en particular, de la cabina 103 de ascensor. Por ejemplo, el controlador 115 puede proporcionar señales de accionamiento a la máquina 111 para controlar la aceleración, desaceleración, nivelación, parada, etc. de la cabina 103 de ascensor. El controlador 115 también puede configurarse para recibir señales de posición del sistema 113 de referencia de posición o de cualquier otro dispositivo de referencia de posición deseado. Al moverse hacia arriba o hacia abajo dentro del hueco 117 de ascensor a lo largo del carril guía 109, la cabina 103 de ascensor puede detenerse en uno o más rellanos 125, según lo controle el controlador 115. Aunque se muestra en una sala 121 de control, los expertos en la técnica apreciarán que el controlador 115 puede ubicarse y/o configurarse en otras ubicaciones o posiciones dentro del sistema 101 de ascensor. En una realización, el controlador puede ubicarse de forma remota o en la nube.

La máquina 111 puede incluir un motor o un mecanismo de accionamiento similar. De acuerdo con las realizaciones de la descripción, la máquina 111 se configura para incluir un motor accionado eléctricamente. La fuente de alimentación para el motor puede ser cualquier fuente de alimentación, incluida una red eléctrica, que, en combinación con otros componentes, se suministra al motor. La máquina 111 puede incluir una polea de tracción que imparte fuerza al miembro tensor 107 para mover la cabina 103 de ascensor dentro del hueco 117 de ascensor.

Aunque se muestra y describe con un sistema de cables que incluye el miembro tensor 107, los sistemas de ascensor que emplean otros métodos y mecanismos para mover una cabina de ascensor dentro de un hueco de ascensor, pueden emplear las realizaciones de la presente descripción. Por ejemplo, las realizaciones pueden emplearse en sistemas de ascensor sin cables que utilicen un motor lineal para impartir movimiento a una cabina de ascensor. Las realizaciones también pueden emplearse en sistemas de ascensor sin cables que utilicen un elevador hidráulico para impartir movimiento a una cabina de ascensor. La FIG. 1 es, meramente, un ejemplo no limitante presentado con fines ilustrativos y explicativos.

En otras realizaciones, el sistema comprende un sistema de transporte que desplaza pasajeros entre plantas y/o a lo largo de una única planta. Dichos sistemas de transporte pueden incluir escaleras mecánicas, transportadores de personas, etc. En consecuencia, las realizaciones descritas en la presente memoria no se limitan a sistemas de ascensor, como el que se muestra en la Figura 1.

Con referencia a la FIG. 2, se muestra una realización de un sistema 200 de procesamiento para implementar las enseñanzas en la presente memoria. En esta realización, el sistema 100 tiene una o más unidades centrales de procesamiento (procesadores) 201a, 201b, 201c, etc. (denominadas colectiva o genéricamente procesador(es) 201). En una realización, cada procesador 201 puede incluir un microprocesador informático de conjunto de instrucciones reducido (RISC). Los procesadores 201 están acoplados a la memoria 214 del sistema y a varios otros componentes a través de un bus 213 del sistema. La memoria de solo lectura (ROM) 202 se acopla al bus 213 del sistema y puede incluir un sistema de entrada/salida básico (BIOS), que controla ciertas funciones básicas del sistema 200.

La FIG. 2 representa además un adaptador 207 de entrada/salida (E/S) y un adaptador 206 de red acoplados al bus 213 del sistema. El adaptador 207 de E/S puede ser un adaptador de interfaz de sistema informático pequeño (SCSI) que se comunica con un disco duro 203 y/o con una unidad 205 de almacenamiento en cinta o con cualquier otro componente similar. El adaptador 207 de E/S, el disco duro 203, y el dispositivo 205 de almacenamiento en cinta se denominan, colectivamente, en la presente memoria almacenamiento masivo 204. Un sistema operativo 220 para su ejecución en el sistema 200 de procesamiento puede almacenarse en el almacenamiento masivo 204. Un adaptador 206 de red interconecta el bus 213 con una red exterior 216 permitiendo que el sistema 200 de procesamiento de datos se comunique con otros sistemas similares. Una pantalla (p. ej., un monitor de visualización) 215 está conectada al bus 213 del sistema mediante un adaptador 212 de visualización, que puede incluir un adaptador gráfico para mejorar el rendimiento de aplicaciones con uso intensivo de gráficos y un controlador de vídeo. En una realización, los adaptadores 207, 206, y 212 pueden conectarse a uno o más buses de E/S que están conectados al bus 213 del sistema a través de un puente de bus intermedio (no mostrado). Los buses de E/S adecuados para conectar dispositivos periféricos como controladores de disco duro, adaptadores de red, y adaptadores gráficos, normalmente, incluyen protocolos comunes, como la Interconexión de Componentes Periféricos (PCI). Dispositivos de entrada/salida adicionales se muestran como conectados al bus 213 del sistema a través de un adaptador 208 de interfaz de usuario y de un adaptador 212 de visualización. Un teclado 209, un ratón 210, y un altavoz 211, todos interconectados al bus 213 a través del adaptador 208 de interfaz de usuario, que puede incluir, por ejemplo, un chip de E/S Super que integra múltiples adaptadores de dispositivos en un único circuito integrado.

En realizaciones ejemplares, el sistema 200 de procesamiento incluye una unidad 230 de procesamiento gráfico. La unidad 230 de procesamiento gráfico es un circuito electrónico especializado diseñado para manipular y alterar la memoria para acelerar la creación de imágenes en una memoria intermedia de tramas destinadas a su salida a una pantalla. En general, la unidad 230 de procesamiento gráfico es muy eficiente en la manipulación de gráficos informáticos y el procesamiento de imágenes, y tiene una estructura, altamente paralela, que la hace más efectiva que las CPUs de propósito general para algoritmos donde el procesamiento de grandes bloques de datos se realiza en paralelo.

De este modo, como se configura en la FIG. 2, el sistema 200 incluye capacidad de procesamiento en forma de procesadores 201, capacidad de almacenamiento que incluye la memoria 214 del sistema y el almacenamiento masivo 204, medios de entrada como el teclado 209 y el ratón 210, y capacidad de salida que incluye el altavoz 211 y la pantalla 215. En una realización, una parte de la memoria 214 del sistema y el almacenamiento masivo 204 almacenan, de forma colectiva, un sistema operativo para coordinar las funciones de los diversos componentes mostrados en la FIG. 2.

En una o más realizaciones, el controlador puede implementarse en el sistema 200 de procesamiento que se encuentra en la FIG. 2. Además, la red 216 puede utilizarse para una comunicación electrónica entre el controlador y otros dispositivos. La red 216 puede estar en comunicación electrónica, por cable o inalámbrica, con uno o con todos los elementos del sistema 200. La computación en la nube puede complementar, soportar o reemplazar parte o la totalidad de la funcionalidad de los elementos del sistema 200. Además, parte o la totalidad de la funcionalidad de los elementos del sistema 200 puede implementarse como un nodo de computación en la nube. La computación en la nube es un modelo de prestación de servicios para permitir un acceso de red conveniente, bajo demanda, a un conjunto compartido de recursos informáticos configurables (p. ej., redes, ancho de banda de red, servidores, procesamiento, memoria, almacenamiento, aplicaciones, máquinas virtuales, y servicios) que se puede suministrar y lanzar, rápidamente, con un mínimo esfuerzo de gestión o interacción con un proveedor del servicio.

El sistema 200 de procesamiento descrito en la presente memoria es meramente ejemplar y no pretende limitar la aplicación, usos, y/o el alcance técnico de la presente descripción, que puede materializarse de diversas formas conocidas en la técnica.

Haciendo referencia ahora a la FIG. 3, se proporciona un sistema 300 para desarrollar un marco modelo para una unida remota que monitorice el mantenimiento basado en la condición. Como se muestra en la FIG. 3, los datos recopilados se almacenan en un archivo 302 de datos. Los datos que se recopilan y almacenan pueden provenir de diversas fuentes que incluyen datos 302A de la unidad, datos 302B de rendimiento, datos 302C del registro de servicio, etc.

Los datos 302A de la unidad incluyen, pero no se limitan a, alarmas y alertas que están relacionadas con la unidad. Además, los datos 302A de la unidad incluyen datos técnicos estáticos asociados a la propia unidad. Por ejemplo, los datos técnicos de una unidad de ascensor pueden incluir, pero no se limitan a, la unidad, modelo, marca, tipo, puertas, segmento de mercado (es decir, hospital, escuela, y apartamento), ubicación geográfica, etc.

Además, los modelos pueden generarse para una población de unidades donde los requisitos para una región geográfica pueden ser diferentes de los de otra región geográfica. En este caso, los modelos pueden generarse en función de una región geográfica específica para predecir si se recibirá una devolución de llamada de un cliente. En otras realizaciones, los modelos pueden generarse en función del tipo de edificio (p. ej., apartamento, hotel, oficina, etc.), tamaño del edificio, u otra agrupación deseada para la población. Al recopilar los datos asociados a la unidad, pueden identificarse varios patrones durante un período de tiempo en función de los diferentes tipos de unidades, en función de los datos estáticos o, en general, puede ser necesario un cierto tipo de reparación entre una variedad de tipos de unidad.

Los datos 302B de rendimiento pueden incluir estadísticas agregadas. Por ejemplo, los datos de rendimiento pueden incluir un número de recorridos de un ascensor, retrocesos de puertas, puertas que funcionan lentamente, puertas que no se abren ni cierran, etc. En una o más realizaciones, los datos 302B de rendimiento pueden proporcionarse desde una unidad remota que monitorice sistemas, como un sistema de monitorización remota de ascensores. Los datos de eventos pueden incluir datos de alarmas y de alertas, donde las alarmas pueden indicar un error en el rendimiento de un sistema, y las alertas pueden incluir las advertencias que fueron proporcionadas y/o activadas por el sistema. En una o más realizaciones, una organización de campo u otros operadores pueden evaluar la precisión del tipo de alarma en particular. Esto informa al mecánico de servicio con conocimiento específico del probable problema asociado a la unidad para proporcionar una visita de mantenimiento más concreta y específica sobre el problema con la unidad.

Los datos 302C del registro de servicio pueden incluir la fecha de una reparación, el tipo de reparación, los componentes reemplazados de una unidad, la duración de la reparación, la reparación exitosa, las quejas de los clientes y el informe de cierre del mecánico de servicio de la queja del cliente, reparaciones programadas o no programadas, reparaciones mayores, programas de mantenimiento normales, etc. Debe entenderse que también pueden incluirse otros tipos de datos en los datos 302C del registro de servicio y no se limitan a los mencionados anteriormente.

En el bloque 304 de procesamiento, las diversas características y etiquetas se procesan y se utilizan para obtener datos de entrenamiento para desarrollar el modelo. En una o más realizaciones, los datos se etiquetarán con la información de devolución de llamada o solicitudes de servicio donde estos son los eventos cuyo historial se analizará más a fondo. En una o más realizaciones, las características pueden extraerse a partir de los datos recopilados en el bloque 304 y utilizarse para generar un modelo utilizado para predecir una devolución de llamada. Cuando se utiliza aprendizaje automático supervisado, se proporciona un módulo de procesamiento con entradas de ejemplo y salidas deseadas, donde se desarrolla una regla general que mapea las entradas a las salidas. Además, el módulo de procesamiento implementa aprendizaje activo obteniendo etiquetas de entrenamiento para un conjunto limitado de instancias que se utiliza para entrenar el modelo en el bloque 312. En un ejemplo, si se recibe una devolución de llamada de un cliente en una fecha en particular, se analizarán los datos del período de tiempo anterior, como dos semanas o más, para determinar qué causó el evento. El modelo será entrenado para buscar una tendencia o patrón de datos que indique que es probable que se produzca un tipo similar de fallo.

En el bloque 306, los datos de modelado se preparan para su procesamiento y se utilizan para desarrollar el modelo en el bloque 308. En una o más realizaciones, los datos de modelado en el bloque 306 proporcionan los datos de entrenamiento y los datos de prueba al bloque 308 de desarrollo del modelo. En una o más realizaciones, el bloque 308 de desarrollo incluye una técnica de árbol de decisión o de bosque de decisión para desarrollar el modelo predictivo que determine cuándo es probable que ocurra una solicitud de servicio. El aprendizaje del árbol de decisión se basa en el uso de árboles de decisión como modelo predictivo para mapear observaciones sobre un elemento con conclusiones sobre el valor objetivo de los elementos. En el bloque 314 de procesamiento, se reciben los datos 312 de entrenamiento de los datos 306 de modelado. Después de entrenar al bloque 314 de procesamiento, se desarrollan varios modelos candidatos 316 para predecir cuándo es probable que se produzca una devolución de llamada de un cliente en función de patrones o tendencias en los datos que experimenta una unidad.

En respuesta a la selección de un modelo de la pluralidad de modelos candidatos 316, el modelo final 318 se proporciona a un bloque 320 de validación posterior para verificar adicionalmente los datos con un conjunto independiente de datos 322 de prueba de los datos 306 de modelado. Tras el bloque 320 de validación final, el modelo se utiliza para predecir una devolución de llamada o solicitud de servicio. El bloque 320 de validación evalúa la precisión del modelo. La evaluación puede realizarse utilizando una evaluación basada en períodos (métricas diarias) o una técnica de evaluación basada en eventos. En un ejemplo, si se utiliza una ventana de 20 días para determinar una solicitud de servicio en el modelo, la evaluación basada en períodos analiza si los eventos que llevaron a la solicitud han ocurrido diariamente, donde una evaluación basada en eventos determina si el evento ha ocurrido en cualquier momento durante la ventana de 20 días. La evaluación basada en eventos puede indicar con qué fiabilidad predice el modelo las devoluciones de llamada.

La salida 330 del desarrollo 308 del modelo incluye un ID de unidad, una puntuación de salud estimada para la unidad identificada, y las características principales que contribuyeron a la puntuación de salud estimada. La puntuación de salud por unidad puede proporcionar una indicación al operador de la probabilidad de tener un evento de solicitud de servicio no planificado en un período de tiempo determinado. La puntuación de salud puede ser un valor entre 0,1 y 1,0, en donde 1,0 indica una alta probabilidad de que se produzca una devolución de llamada durante una ventana de tiempo específica. Debe entenderse que pueden utilizarse otras escalas para representar la probabilidad estadística de devolución de llamada basada en los datos de entrenamiento.

En una o más realizaciones, los modelos se generan utilizando técnicas de aprendizaje automático. El modelo busca la evidencia de datos que se ha recopilado y almacenado durante una ventana de tiempo previa a la devolución de llamada de un cliente. Se busca la misma evidencia para predecir si se producirá un evento como una devolución de llamada de un cliente. En una o más realizaciones, pueden determinarse diversas tendencias y patrones para una unidad que indiquen una unidad sana o no sana. Por ejemplo, en un algoritmo de aprendizaje automático supervisado, los datos de los 20 días anteriores a una devolución de llamada pueden utilizarse para entrenar el modelo. En este ejemplo, la estrategia de etiquetado del aprendizaje automático supervisado está impulsada por las quejas de los clientes. Debe entenderse que pueden utilizarse otras estrategias de etiquetado, como reportes del personal técnico, paquetes de sensores actualizados, etc.

Haciendo referencia ahora a la FIG. 4, un diagrama de flujo de un método 400 para desarrollar un marco modelo para un mantenimiento basado en la condición de monitorización remota de acuerdo con una o más realizaciones. En el bloque 402, el método 400 comienza y procede al bloque 404, que proporciona la recopilación de datos asociada a una solicitud de servicio no planificada. En una o más realizaciones, en respuesta a la recepción de una devolución de llamada de un cliente, se obtienen datos históricos para analizar los eventos y/o síntomas operativos del sistema que llevaron a la queja del cliente. Los datos incluyen datos técnicos estáticos de la unidad, datos operativos y de rendimiento, como alarmas y alertas, datos del registro de servicio, como información de devolución de llamadas, etc.

El método 400, en el bloque 406, que proporciona la generación de más de un modelo a partir de los datos recopilados. En una o más realizaciones, los datos pueden analizarse utilizando una técnica de aprendizaje automático, como un aprendizaje automático supervisado. Por ejemplo, los datos etiquetados se proporcionan al módulo de procesamiento para su entrenamiento. En una o más realizaciones, los datos etiquetados son "solicitudes de servicio" o devoluciones de llamada. En caso de recibir una devolución de llamada, se analizan los datos que se reciben en un intervalo o ventana de tiempo anterior a la solicitud de servicio. Puede generarse un modelo para la solicitud de servicio donde se puede marcar e investigar más a fondo un conjunto de datos que indica un conjunto común de condiciones o un patrón de síntomas operativos. Se generan múltiples modelos candidatos en función de los datos que se han recopilado a lo largo del tiempo. En respuesta a la generación de múltiples modelos candidatos a partir de los datos, se selecciona un modelo final de los modelos candidatos. En una o más realizaciones, puede utilizarse un esquema de validación cruzada (CV) de k veces (dondekes un número entero) para seleccionar el modelo final. Por ejemplo, en un esquema CV de 5 veces donde k = 5, los datos de entrenamiento pueden dividirse en 5 particiones iguales (A, B, C, D, y E). El entrenamiento se realiza en las particiones BCDE, y el rendimiento se valida utilizando la partición A como conjunto de validación. Se realiza un seguimiento de una puntuación representativa del rendimiento del modelo. En la siguiente iteración, el entrenamiento se realiza en las particiones ACDE, se valida en la partición B, y se realiza un seguimiento de la puntuación representativa del rendimiento. El esquema CV itera a través de todas las particiones y el rendimiento final se promedia, donde se selecciona como modelo final el modelo que da como resultado la puntuación de rendimiento de validación cruzada mejor u óptima. El modelo final puede verificarse utilizando datos de prueba independientes con salidas esperadas que pueden utilizarse para optimizar aún más el modelo predictivo. Debe entenderse que pueden utilizarse otras técnicas para seleccionar el modelo final.

En el bloque 408, el método 400 proporciona la predicción de una solicitud de servicio no planificada basada, al menos en parte, en más de un modelo. En respuesta a la generación del modelo, puede predecirse una devolución de llamada de un cliente por un problema. En una o más realizaciones, puede adaptarse un programa de mantenimiento o una visita de servicio para abordar el problema previsto antes de recibir una devolución de llamada de un cliente en relación con un problema con la unidad.

El bloque 410 proporciona la transmisión de una salida del modelo. La salida del modelo puede incluir información como el ID de la unidad, una puntuación de salud estimada para la unidad, y las características principales que contribuyeron a la puntuación de salud estimada. El ID de la unidad identifica la unidad que es objeto de la potencial devolución de llamada de un cliente. La puntuación de salud estimada está relacionada con la probabilidad de un evento de solicitud de servicio. Las características principales pueden proporcionarse al mecánico de servicio o utilizarse durante el mantenimiento para llevar a cabo una reparación más específica y/o focalizada. Además, el mecánico de servicio recibe la información que condujó a la devolución de llamada antes de realizar el servicio. Debe entenderse que la información que genera el modelo puede actualizarse con el tiempo. El método 400 termina en el bloque 412.

Con referencia ahora a la FIG. 5, se muestra, en general, un producto 500 de programa informático de acuerdo con una realización que incluye un medio 502 de almacenamiento legible por ordenador e instrucciones 504 del programa.

Los efectos y beneficios técnicos incluyen el uso de un modelo basado en datos que utiliza el aprendizaje automático para predecir un modelo para obtener ganancias de eficiencia operativas que resultan de conocimientos predictivos y específicos que indican que una unidad no está sana, donde una unidad no sana puede dar lugar a una solicitud de servicio no planificada. Los efectos y beneficios técnicos del proceso de modelado incluyen lograr un modelo predictivo más eficaz, personalizado para los datos disponibles determinados de forma estandarizada y automatizada.

Como se ha descrito anteriormente, las realizaciones pueden ser en forma de procesos y dispositivos implementados por un procesador para poner en práctica esos procesos, como un procesador. Las realizaciones también pueden ser en forma de código de programa informático, que contiene instrucciones, incorporado en medios tangibles, como almacenamiento en la nube en red, tarjetas SD, unidades flash, disquetes, CD ROMs, discos duros, o cualquier otro medio de almacenamiento legible por ordenador, en donde, cuando el código de programa informático se carga en, y es ejecutado por, un ordenador, el ordenador se convierte en un dispositivo para poner en práctica las realizaciones. Las realizaciones también pueden ser en forma de código de programa informático, por ejemplo, ya sea almacenado en un medio de almacenamiento, cargado en y/o ejecutado por un ordenador, o transmitido a través de algún medio de transmisión, cargado en y/o ejecutado por un ordenador, o transmitido a través de algún medio de transmisión, como a través de cableado o cableado eléctrico, fibra óptica, o radiación electromagnética, en donde, cuando el código de programa informático se carga en, y es ejecutado por, un ordenador, el ordenador se convierte en un dispositivo para poner en práctica las realizaciones. Cuando se implementa en un microprocesador de uso general, los segmentos del código de programa informático configuran el microprocesador para crear circuitos lógicos específicos.

El término "sobre" pretende incluir el grado de error asociado a la medida de la cantidad en particular y/o las tolerancias de fabricación en función del equipo disponible en el tiempo de presentar la solicitud.

La terminología utilizada en la presente memoria tiene el propósito de describir solo realizaciones en particular y no pretende limitar la presente descripción. Como se utiliza en la presente memoria, las formas singulares "un", "una" y "el/la" pretenden incluir también las formas plurales, a menos que el contexto indique claramente lo contrario. Se comprenderá además que los términos "comprende" y/o "que comprende", cuando se utilizan en esta especificación, especifican la presencia de características, números enteros, pasos, operaciones, elementos, y/o componentes indicados, pero no excluyen la presencia o adición de una o más de otras características, números enteros, pasos, operaciones, componentes de elementos, y/o grupos de los mismos.

Los expertos en la técnica apreciarán que en la presente memoria se muestran y describen diversas realizaciones de ejemplo, cada una con ciertas características en las realizaciones en particular, pero la presente descripción no se limita a ello. En consecuencia, la presente descripción no debe verse como limitada por la anterior descripción, sino que está solo limitada por el alcance de las reivindicaciones adjuntas.

Claims (15)

REIVINDICACIONES

1. Un sistema (300) para desarrollar un marco modelo para una unidad remota que monitorice el mantenimiento basado en la condición, comprendiendo el sistema (300):

un medio (204) de almacenamiento, estando acoplado el medio de almacenamiento a un procesador (201); el procesador (201) configurado para:

recopilar datos asociados a solicitudes de servicios no planificadas;

generar más de un modelo a partir de los datos recopilados;

predecir una solicitud de servicio no planificada basada, al menos en parte, en los modelos; y

transmitir una salida de la predicción de la solicitud de servicio no planificada.

2. El sistema (300) de la reivindicación 1, en donde los datos recopilados comprenden, al menos, uno de datos (302A) de la unidad, datos (302B) de rendimiento, o registros (302C) de servicio.

3. El sistema (300) de la reivindicación 2, en donde los datos recopilados comprenden, al menos, dos de los datos (302A) de la unidad, datos (302B) de rendimiento, o registros (302C) de servicio.

4. El sistema (300) de la reivindicación 2, en donde los datos recopilados comprenden los datos (302A) de la unidad, los datos (302B) de rendimiento, y los registros (302C) de servicio.

5. El sistema (300) de cualquiera de las reivindicaciones anteriores, en donde los modelos se generan utilizando un proceso de aprendizaje automático supervisado.

6. El sistema (300) de la reivindicación 4, en donde la generación de más de un modelo comprende generar una puntuación de salud para la unidad (101).

7. El sistema (300) de cualquiera de las reivindicaciones anteriores, en donde el procesador (201) se configura para seleccionar un modelo de más de un modelo, y probar el modelo seleccionado en función de un conjunto de datos independiente de los datos recopilados.

8. El sistema (300) de cualquiera de las reivindicaciones anteriores, la salida comprende, al menos, una de un ID de la unidad, una puntuación estimada relacionada con la probabilidad de una solicitud de solicitud de servicio, y una o más características que contribuyeron a la puntuación estimada.

9. Un método para desarrollar un marco modelo para una unidad remota que monitorice el mantenimiento basado en la condición, comprendiendo el método:

recopilar datos asociados a solicitudes de servicio no planificadas;

generar más de un modelo a partir de los datos recopilados;

predecir solicitudes de servicio no planificadas basadas, al menos en parte, en más de un modelo; y transmitir una salida de la predicción de la solicitud de servicio no planificada.

10. El método de la reivindicación 9, en donde los datos comprenden, al menos, uno de datos (302A) de la unidad, datos (302B) de rendimiento, o registros (302C) de servicio,

preferiblemente, los datos comprenden, al menos, dos de los datos (302A) de la unidad, datos (302B) de rendimiento, o registros (302C) de servicio,

y más preferiblemente, los datos comprenden datos (302A) de la unidad, datos (302B) de rendimiento, y registros (302C) de servicio.

11. El método de la reivindicación 9 o reivindicación 10, en donde la solicitud de servicio no planificado es para una unidad, en donde la unidad es, al menos, una de una unidad (101) de ascensor o una unidad de escalera mecánica.

y/o

en donde los modelos se generan utilizando un proceso de aprendizaje automático supervisado.

12. El método de cualquiera de las reivindicaciones 9 a 11, en donde la generación de uno o más modelos comprende generar una puntuación de salud para la unidad.

13. El método de cualquiera de las reivindicaciones 9 a 12, que comprende además seleccionar un modelo de más de un modelo, y probar el modelo seleccionado en función de un conjunto de datos independiente de los datos recopilados.

14. El método de cualquiera de las reivindicaciones 9 a 13, en donde la salida comprende, al menos, una de un ID de la unidad, una puntuación estimada relacionada con la probabilidad de una solicitud de solicitud de servicio, y una o más características que contribuyeron a la puntuación estimada.

15. El método de la reivindicación 14, en donde el método comprende además actualizar un programa de mantenimiento basado, al menos en parte, en la salida.