ES2675844T3

ES2675844T3 - Sistema de identificación de fallos de comunicación de red de grandes cantidades de datos de telemáticas

Info

Publication number: ES2675844T3
Application number: ES17204578T
Authority: ES
Inventors: Neil Charles Cawse; Daniel Michael Dodgson; Yi Zhao
Original assignee: Geotab Inc
Current assignee: Geotab Inc
Priority date: 2016-12-05
Filing date: 2017-11-30
Publication date: 2020-01-24
Anticipated expiration: 2037-11-30
Also published as: EP3496430B8; PL3331259T3; EP3496430B1; DE17204578T1; TR201911002T4; ES2720729T3; EP3331259B1; TR201910016T3; ES2720729T1; ES2675844T1; EP3331259A1; EP3496430A1; DE19154673T1; PL3496430T3

Abstract

Un sistema de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas que comprende: al menos un dispositivo móvil, y l menos un dispositivo remoto, pudiendo comunicar dicho dispositivo móvil y dicho dispositivo remoto al menos una de una señal o datos o un mensaje, incluyendo dicho dispositivo móvil un estado de modo de comunicación esperado para comunicación oportuna de dicho al menos uno de una señal o datos o mensaje con dicho dispositivo remoto, incluyendo dicho dispositivo remoto un estado de determinación de fallo de comunicación, n el que dicho estado de determinación de fallo de comunicación monitoriza comunicación esperada para cada uno de dicho al menos un dispositivo móvil y dicho estado de determinación de fallo de comunicación monitoriza comunicación real para cada uno de dicho al menos un dispositivo móvil para determinar un fallo cuando dicha comunicación real es diferente de dicha comunicación esperada.

Description

DESCRIPCIÓN

Sistema de identificación de fallos de comunicación de red de grandes cantidades de datos de telemáticas REFERENCIA CRUZADA A SOLICITUD DE PATENTE RELACIONADA

Esta solicitud de patente es una solicitud de patente de continuación en parte a la solicitud de patente estadounidense número de serie 14/757.112 presentada el 20 de noviembre de 2015.

Campo técnico de la invención

La presente invención se refiere en general a un dispositivo, método y sistema de grandes datos de telemáticas para aplicación en entornos de telemetría vehicular. De manera más específica, la presente invención se refiere a un sistema móvil de identificación de fallos de comunicación de red de datos de telemáticas en tiempo real.

Antecedentes de la invención

Los sistemas de telemetría vehicular son conocidos en la técnica anterior, donde un vehículo puede estar equipado con un dispositivo de hardware de telemetría vehicular para monitorizar y registrar una serie de parámetros del vehículo. Un ejemplo de tal dispositivo es un dispositivo Geotab™ GO. El dispositivo Geotab GO se conecta al vehículo a través de un puerto de diagnóstico a bordo (OBD) para acceder a la red del vehículo y la unidad de control del motor. Una vez interconectados y operativos, el dispositivo Geotab GO monitoriza el bus del vehículo y crea un registro de datos sin procesar del vehículo. El dispositivo Geotab GO puede mejorarse aún más a través de un expansor E/S Geotab para acceder y monitorizar otras variables, sensores y dispositivos que resultan en un registro más complejo y más grande de datos sin procesar. Adicionalmente, el dispositivo Geotab GO puede incluir además una capacidad GPS para rastrear y registrar datos GPS sin procesar. El dispositivo Geotab GO también puede incluir un acelerómetro para monitorizar y registrar datos del acelerómetro sin procesar. La operación en tiempo real de una pluralidad de dispositivos Geotab GO crea y comunica múltiples registros complejos de algunos o todos estos datos sin procesar combinados a un sitio remoto para su posterior análisis.

Los datos se consideran datos de telemáticas grandes debido a la complejidad de los datos sin procesar, la velocidad de los datos sin procesar, la variedad de los datos sin procesar, la variabilidad de los datos sin procesar y el volumen significativo de datos sin procesar que se comunican a un sitio remoto de manera oportuna. Por ejemplo, el 10 de diciembre de 2014 había aproximadamente 250.000 dispositivos Geotab GO en monitorización activa de operación, rastreando y comunicando múltiples registros complejos de grandes cantidades de datos de telemáticas sin procesar a un centro de datos Geotab. El volumen de grandes cantidades de datos de telemáticas sin procesar en un solo día superó los 300 millones de registros y más de 40 GB de grandes cantidades de datos de telemáticas sin procesar.

El enfoque anterior para transformar la gran cantidad de datos de telemáticas sin formato en un formato para usar con una base de datos SQL y el proceso analítico correspondiente fue retrasar y copiar cada día completo de la gran cantidad de datos de telemáticas sin procesar a una base de datos separada donde se podrían procesar la gran cantidad de datos de telemáticas sin procesar descodificados en un formato que podría proporcionar un valor significativo en un proceso de análisis. Este enfoque anterior consume recursos y normalmente se ejecuta durante la noche cuando la cantidad de dispositivos Geotab GO activos es mínima. En este ejemplo, el procesamiento y la decodificación de la gran cantidad de datos de telemáticas sin formato requirió más de 12 horas por cada día de la gran cantidad de datos de telemáticas sin procesar. El proceso de análisis y la correspondiente información útil para los administradores de flotas que realizan actividades de gestión de flotas tiene al menos 1,5 días de antigüedad, influyendo negativamente en cualquier decisión de gestión de la flota sensible en tiempo real.

Los enfoques anteriores para monitorizar grandes cantidades de datos de telemáticas para fallos de comunicación de red fueron limitados previamente debido al procesamiento y a los retrasos en la recepción de datos. Estos retrasos en los datos y la falta de datos aumentados o complementados también afectaron a la capacidad de determinar la ubicación de un fallo de comunicación de la red en función de las coordenadas del dispositivo móvil en tiempo real. El documento US2015031308A1 publicado se dirige a la detección de huecos de cobertura en la red mediante el registro de mediciones de minimización registradas de la prueba de gestión (MDT) (240) a una velocidad seleccionada, cuando el UE está en modo inactivo de control de recursos de radio (RRC). Las mediciones MDT registradas disminuyen la cantidad de datos comunicados desde el UE a la red. La disminución en la cantidad de datos disminuye el tiempo de procesamiento y la potencia de procesamiento necesaria para determinar los huecos de cobertura.

Sumario de la invención

La presente invención está dirigida a aspectos en un entorno de telemetría vehicular. La presente invención proporciona una nueva capacidad para un sistema de identificación de fallos de comunicación de datos de grandes cantidades de datos de telemáticas en tiempo real de dispositivos móviles.

De acuerdo con un aspecto amplio de la invención, hay un sistema de identificación de fallos de comunicación de red de grandes cantidades de datos de telemáticas. El sistema incluye al menos un dispositivo móvil y al menos un dispositivo remoto. El dispositivo móvil y el dispositivo remoto son capaces de comunicar al menos una de una señal o datos o mensaje. El dispositivo móvil incluye un estado de modo de comunicación esperado para la comunicación oportuna de al menos uno de una señal o datos o mensaje con el dispositivo remoto. El dispositivo remoto incluye un estado de determinación de fallos de comunicación. El estado de determinación de fallos de comunicación controla la comunicación esperada para cada uno del al menos un dispositivo móvil y el estado de determinación de fallos de comunicación monitoriza la comunicación real para cada uno del al menos un dispositivo móvil para determinar una fallo cuando la comunicación real es diferente de la comunicación esperada.

El estado de modo de comunicación esperado puede incluir un estado de modo activo y un estado de modo inactivo. El estado de modo inactivo puede incluir además un estado de suspensión. El estado de modo inactivo puede incluir además un estado de suspensión profunda. El estado del modo activo puede incluir además un primer período de comunicación oportuna para comunicarse con el dispositivo remoto. El estado de suspensión puede incluir además un segundo período de comunicación oportuna para comunicarse con el dispositivo remoto. El estado de suspensión profunda puede incluir además un tercer período de comunicación oportuna para la comunicación del dispositivo remoto. El primer período de comunicación oportuna puede establecer además una primera comunicación esperada. El segundo período de comunicación oportuna puede establecer una segunda comunicación esperada. El tercer período de comunicación oportuna puede establecer una tercera comunicación esperada. En una realización de la invención, la primera comunicación esperada es un periodo de 100 segundos. En una realización de la invención, la segunda comunicación esperada es un período de 1800 segundos. En una realización de la invención, la tercera comunicación esperada es un período de 86.400 segundos. El estado de modo de comunicación esperado puede incluir además una pluralidad de periodos de comunicación oportunos. La pluralidad de periodos de comunicación oportunos puede ser además intervalos de tiempo diferentes. Los diferentes intervalos de tiempo pueden incluir además al menos una frecuencia de comunicación. En una realización de la invención, la al menos una frecuencia de comunicación incluye un período de 100 segundos. En otra realización de la invención, la al menos una frecuencia de comunicación incluye un período de 1800 segundos. En otra realización de la invención, la al menos una frecuencia de comunicación incluye un período de 86.400 segundos.

El dispositivo móvil puede incluir además un dispositivo posicional, incluyendo el dispositivo posicional una indicación de posición del dispositivo móvil con la comunicación de al menos uno de una señal o datos o mensaje en el que el dispositivo remoto determina la ubicación de un fallo de comunicación mediante una última indicación de posición conocida del dispositivo móvil.

El método puede incluir además el al menos un primer proceso concurrente que determina un modo activo o un modo inactivo mediante la detección del estado de un vehículo. La detección del estado de un vehículo puede basarse además en el estado de encendido de un vehículo. El estado del vehículo puede proporcionar además una indicación para configurar un modo activo. El modo activo puede incluir además un primer período de comunicación oportuno para comunicarse con al menos un dispositivo remoto. El estado del vehículo puede proporcionar además una indicación para establecer un modo inactivo. El modo inactivo puede incluir además un segundo período de comunicación oportuna para comunicarse con al menos un dispositivo remoto. El modo inactivo puede incluir además un tercer período de comunicación oportuna para la comunicación con al menos un dispositivo remoto. El modo inactivo puede incluir además una segunda comunicación esperada y una tercera comunicación esperada. En una realización de la invención, la segunda comunicación esperada y la tercera comunicación esperada pueden basarse además en un tiempo de 86.400 segundos y en exceder el tiempo de 86.400 segundos, pasando de la segunda comunicación esperada a la tercera comunicación esperada. El segundo proceso concurrente puede determinar además un modo activo o un modo inactivo para cada uno de al menos un dispositivo móvil. El modo activo y el modo inactivo pueden determinarse adicionalmente a partir de la señal, o datos, o mensaje. El estado de encendido de un vehículo puede estar contenido además en la señal, o datos, o mensaje para determinar un modo activo o un modo inactivo. El modo activo puede incluir además un primer período de comunicación oportuna para comunicarse con el dispositivo remoto. El modo inactivo puede incluir además un segundo período de comunicación oportuna para comunicación con al menos un dispositivo remoto. El modo inactivo puede incluir además un tercer período de comunicación oportuna para la comunicación con al menos un dispositivo remoto.

El al menos un período de comunicación esperado puede basarse además en un modo activo. El modo activo puede incluir además un primer período de comunicación oportuna para comunicarse con el dispositivo remoto. El al menos un período de comunicación esperado puede basarse además en un modo inactivo. El modo inactivo puede incluir además un segundo período de comunicación oportuna para comunicarse con el dispositivo remoto. El modo inactivo puede incluir además un tercer período de comunicación oportuna para comunicarse con el dispositivo remoto.

En una realización de la invención, el dispositivo móvil es un sistema de hardware de telemetría 30. El sistema de hardware de telemetría 30 incluye un microprocesador de telemetría DTE 31, un microprocesador de comunicaciones 32 y una memoria. El microprocesador de comunicaciones 32 puede habilitarse para comunicaciones celulares, comunicaciones por satélite u otra forma de comunicación para la comunicación con un dispositivo remoto. El sistema de hardware de telemetría 30 también puede incluir un expansor E/S 50. Un dispositivo de posición puede ser parte integral del sistema de hardware de telemetría 30, tal como el módulo GPS 33 o el dispositivo de posición puede ser accesible a través de la interfaz de mensajería 53 o un expansor E/S 50. El sistema de hardware de telemetría 30 también puede incluir un acelerómetro 34. Un ejemplo de dispositivo móvil es un dispositivo Geotab™ GO.

En una realización de la invención, el dispositivo remoto es al menos un servidor de propósito especial 19 con software de aplicación. En realizaciones alternativas, el dispositivo remoto puede ser uno o más dispositivos informáticos 20 (ordenadores de escritorio, dispositivos de mano, ordenadores de teléfono inteligente, ordenadores de tableta, ordenadores portátiles, dispositivos portátiles y otros dispositivos informáticos con software de aplicación). La aplicación puede ser residente con el dispositivo remoto 44 o accesible a través de computación en la nube. Un ejemplo de software de aplicación es la aplicación de gestión de flotas MyGeotab™.

En una realización de la invención, la señal, datos, o mensaje es una comunicación que incluye señales, datos y/o comandos. Las personas expertas en la técnica consideran que otras formas de comunicación están contempladas por las invenciones. En una realización de la invención, los datos son en forma de un registro histórico de datos e información.

En una realización de la invención, el estado del vehículo se basa en datos e información del vehículo. Un ejemplo de estado del vehículo es el estado de encendido de "ON" u "OFF". El estado del vehículo también se puede seleccionar de uno o más indicadores adicionales del estado del vehículo a partir de los datos e información del vehículo.

Estos y otros aspectos y características de las realizaciones no limitativas son evidentes para los expertos en la materia tras la revisión de la siguiente descripción detallada de las realizaciones no limitativas y los dibujos adjuntos. Las realizaciones de la invención se llevan a cabo de acuerdo con la reivindicación independiente adjunta. Las realizaciones en el presente documento están limitadas solamente por la reivindicación independiente adjunta.

Breve descripción de los dibujos

Ejemplos de realizaciones no limitativas de la presente invención se describen con referencia a los dibujos adjuntos, en los que:

La figura 1 es una vista esquemática de alto nivel de un entorno e infraestructura de datos de telemetría vehicular;

La figura 2a es una vista esquemática de un sistema de hardware de telemetría vehicular que incluye una porción a bordo y una porción vehicular residente;

La figura 2b es una vista esquemática de un sistema de hardware de telemetría vehicular que se comunica con al menos un expansor E/S inteligente;

La figura 2c es una vista esquemática de un sistema de hardware de telemetría vehicular con un módulo Bluetooth™ integral capaz de comunicarse con al menos un módulo de baliza;

La figura 2d es una vista esquemática de al menos un expansor E/S inteligente con un módulo Bluetooth integral capaz de comunicarse con al menos un módulo de baliza;

La figura 2e es una vista esquemática de un expansor E/S inteligente y un dispositivo capaz de comunicarse con al menos un módulo de baliza;

La figura 3 es una vista esquemática de un entorno analítico de telemetría vehicular que incluye una red, dispositivos móviles, servidores y dispositivos informáticos;

La figura 4 es una vista esquemática de una red de telemetría vehicular que ilustra el flujo de grandes cantidades de datos de telemáticas sin procesar entre los dispositivos móviles y los servidores;

La figura 5 es una vista esquemática de una red de telemetría vehicular que ilustra el flujo analítico de grandes cantidades de datos de telemáticas entre los servidores y los dispositivos informáticos;

La figura 6a es una representación esquemática de una realización del constructor analítico de grandes cantidades de datos de telemáticas; La figura 6b es una representación esquemática de una realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra una pluralidad de tipo de datos preservados;

La figura 6c es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además una pluralidad de datos de alteración y tipos de datos modificados;

La figura 7a es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además una primera memoria intermedia para acomodar el amplicador de datos y la recepción de las grandes cantidades de datos de telemáticas sin procesar y los datos complementarios;

La figura 7b es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además una segunda memoria intermedia para acomodar un retraso o errores en el flujo de datos a través del constructor analítico de grandes cantidades de datos de telemáticas;

La figura 7c es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además una combinación de la primera y la segunda memoria intermedia;

La figura 8a es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además un par de servidores de información complementarios para datos de traducción y datos de aumento;

La figura 8b es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además un servidor de información complementario para datos de traducción;

La figura 8c es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además un servidor de información complementario para datos de aumento;

La figura 9a es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además una primera memoria intermedia para acomodar el modificador de datos y un par de servidores de información complementarios para datos de traducción y datos de aumento;

La figura 9b es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además una primera memoria intermedia para acomodar el modificador de datos y un servidor de información complementario para datos de traducción;

La figura 9c es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además una primera memoria intermedia para acomodar el modificador de datos y un servidor de información complementario para datos de aumento;

La figura 10a es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además una primera memoria intermedia para acomodar el modificador de datos, una segunda memoria intermedia para acomodar un retraso o errores en el flujo de datos a través del constructor analítico de grandes cantidades de datos de telemáticas y un par de servidores de información complementarios para datos de traducción y datos de aumento;

La figura 10b es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además una primera memoria intermedia para acomodar el modificador de datos, una segunda memoria intermedia para acomodar un retraso o errores en el flujo de datos a través del constructor analítico de grandes cantidades de datos de telemáticas y un servidor de información complementario para los datos de traducción;

La figura 10c es una representación esquemática de otra realización del constructor analítico de grandes cantidades de datos de telemáticas que ilustra además una primera memoria intermedia para acomodar el modificador de datos, una segunda memoria intermedia para acomodar un retraso o errores en el flujo de datos a través del constructor analítico de grandes cantidades de datos de telemáticas y un servidor de información complementario para datos de aumento;

La figura 11 es una representación esquemática de otra realización de la invención que ilustra ejemplos de grandes cantidades de datos de telemáticas sin procesar, datos de traducción, datos de aumento y analítica de grandes cantidades de datos de telemáticas;

La figura 12a es una representación esquemática de la máquina de estado de la lógica de construcción de grandes cantidades de datos de telemáticas analíticas en tiempo real;

La figura 12b es una representación esquemática de la máquina de estado de la lógica de construcción de grandes cantidades de datos de telemáticas analíticas en tiempo real, que ilustra además una serie de subestados del modificador de datos;

La figura 12c es una representación esquemática de la máquina de estado de la lógica de construcción de grandes cantidades de datos de telemáticas analíticas en tiempo real que ilustra, además, un par de ejemplos de subestados del modificador de datos para traducir datos y aumentar datos;

La figura 13a es una representación esquemática de la lógica de estado del segregador de datos y las tareas para el procesamiento secuencial;

La figura 13b es una representación esquemática alternativa de la lógica de estado del segregador de datos y las tareas para el procesamiento en paralelo;

La figura 13c es una representación esquemática de la lógica y las tareas del estado del modificador de datos; La figura 13d es una representación esquemática de la lógica de estado del amalgamador de datos y las tareas para el procesamiento secuencial;

La figura 13e es una representación esquemática de la lógica de estado del amalgamador de datos y las tareas para el procesamiento en paralelo; La figura 13f es una representación esquemática de la lógica de estado de transferencia de datos y las tareas;

La figura 14a es una representación esquemática de una representación de estado para determinar un fallo de comunicación de red basado en comunicaciones esperadas y comunicaciones reales;

La figura 14b, es una representación esquemática del preprocesamiento de datos para determinar un fallo de comunicación de red basado en la comunicación esperada y un período de comunicación real;

La figura 15 es una representación esquemática de la lógica de determinación del período de comunicación esperado para un dispositivo móvil;

La figura 16a es una representación esquemática de la lógica del dispositivo remoto para determinar el estado activo o inactivo de cada dispositivo móvil;

La figura 16b es una representación esquemática de la lógica del dispositivo remoto para determinar la comunicación esperada para cada dispositivo móvil;

La figura 16c es una representación esquemática de la lógica del dispositivo remoto para determinar un fallo basado en la comunicación esperada y la comunicación real; y

La figura 17 es una representación esquemática de la lógica de indicación de fallos de comunicación de la red del dispositivo remoto.

Los dibujos no están necesariamente a escala y pueden ser representaciones esquemáticas de las realizaciones no limitativas ejemplares de la presente invención.

Descripción detallada

Entorno e infraestructura de telemetría vehicular

Refiriéndose a la figura 1 de los dibujos, se ilustra una descripción general de alto nivel de un entorno e infraestructura de telemetría vehicular. Hay al menos un vehículo generalmente indicado en 11. El vehículo 11 incluye un sistema de hardware de telemetría vehicular 30 y una porción vehicular residente 42. Opcionalmente conectado al sistema de hardware de telemetría 30 hay al menos un expansor E/S inteligente 50 (no mostrado). Además, puede haber al menos un módulo Bluetooth 45 (no mostrado) para la comunicación con al menos uno de los sistemas de hardware de telemetría del vehículo 30 o el expansor E/S inteligente 50.

El sistema de hardware de telemetría vehicular 30 monitoriza y registra una primera categoría de datos de telemáticas sin procesar conocidos como datos del vehículo. El sistema de hardware de telemetría vehicular 30 también puede monitorizar y registrar una segunda categoría de datos de telemáticas sin procesar conocidos como datos de coordenadas de GPS. El sistema de hardware de telemetría vehicular 30 también puede monitorizar y registrar una tercera categoría de datos de telemáticas sin procesar conocidos como datos de acelerómetro.

El expansor E/S inteligente 50 también puede monitorizar una cuarta categoría de datos de expansor sin procesar. También se puede proporcionar una cuarta categoría de datos sin procesar al sistema de hardware de telemetría vehicular 30 para el registro como datos de telemáticas sin procesar.

El módulo Bluetooth 45 también puede estar en comunicación periódica con al menos una baliza Bluetooth 21. La al menos una baliza Bluetooth puede estar conectada o fijada o asociada con al menos un objeto asociado con el vehículo 11 para proporcionar un rango de indicaciones con respecto a los objetos. Estos objetos incluyen, pero no se limitan a paquetes, equipo, conductores y personal de soporte. El módulo Bluetooth 45 proporciona esta quinta categoría de datos de objetos Bluetooth sin procesar al sistema de hardware de telemetría del vehículo 30, ya sea directa o indirectamente a través de un expansor E/S inteligente 50 para el posterior registro como datos de telemáticas sin procesar.

Los expertos en la materia apreciarán que las cinco categorías de datos son ilustrativas y pueden incluir además otras categorías de datos. En este contexto, una categoría de datos de telemáticas sin procesar es una agrupación o clasificación de un tipo de datos similares. Una categoría puede ser un conjunto completo de datos de telemáticas sin procesar o un subconjunto de los datos de telemáticas sin procesar. Por ejemplo, los datos de coordenadas GPS son un grupo o tipo de datos similares. Los datos del acelerómetro son otro grupo o tipo de datos similares. Un registro puede incluir tanto datos de coordenadas de GPS como datos de acelerómetro o un registro puede ser datos separados. Los expertos en la materia también aprecian la formación, el formato y la variedad de cada registro de datos de telemáticas sin procesar en cada una de las cinco categorías es complejo y significativamente diferente. La cantidad de datos en cada una de las cinco categorías también es significativamente diferente y la frecuencia y el tiempo para comunicar los datos pueden variar mucho. Los expertos en la materia aprecian aún más la monitorización, el registro y la comunicación de múltiples registros o datos de telemáticas sin procesar dan como resultado la creación de grandes cantidades de datos de telemáticas sin procesar.

El entorno y la infraestructura de telemetría vehicular también proporcionan comunicación e intercambio de datos de telemáticas sin procesar, información, comandos y mensajes entre el al menos un servidor de propósito especial 19, al menos un dispositivo informático 20 (ordenadores de escritorio, dispositivos de mano, ordenadores de teléfono inteligente, ordenadores de tableta, ordenadores portátiles, dispositivos portátiles y otros dispositivos informáticos), y vehículos 11. En un ejemplo, la comunicación 12 es a/desde un satélite 13. El satélite 13, a su vez, se comunica con un sistema basado en tierra 15 conectado a una red informática 18. En otro ejemplo, la comunicación 16 es a/desde una red celular 17 conectada a la red informática 18. Otros ejemplos de dispositivos de comunicación incluyen dispositivos Wi-Fi y dispositivos Bluetooth conectados a la red informática 18.

El dispositivo de computación 20 y el servidor de propósito especial 19 con el software de aplicación correspondiente se comunican a través de la red informática 18. En una realización de la invención, el software de la aplicación de administración de flotas MyGeotab™ se ejecuta en un servidor de propósito especial 19. El software de la aplicación también puede estar basado en computación en la nube. Los clientes que operan un dispositivo informático 20 se comunican con el software de aplicación de administración de flotas MyGeotab que se ejecuta en el servidor de propósito especial 19. Datos, información, mensajes y comandos pueden enviarse y recibirse a través del entorno de comunicación e infraestructura entre el sistema de hardware de telemetría vehicular 30 y el servidor de propósito especial 19.

Los datos y la información pueden ser enviados desde el sistema de hardware de telemetría vehicular 30 a la red celular 17, a la red informática 18, y al menos a un servidor de propósito especial 19. Los dispositivos de computación 20 pueden acceder a los datos e información en los servidores de propósito especial 19. Alternativamente, datos, información, y comandos pueden ser enviados desde al menos un servidor de propósito especial 19, a la red 18, a la red celular 17, y al sistema de hardware de telemetría vehicular 30.

Los datos y la información también pueden enviarse desde el sistema de hardware de telemetría vehicular a un expansor E/S inteligente 50, a un dispositivo Iridium™, el satélite 13, la estación de tierra 15, la red informática 18, y al menos a un servidor de propósito especial 19. Los dispositivos de computación 20 pueden acceder a datos e información en los servidores de propósito especial 19. Datos, información, y comandos también pueden ser enviados desde el al menos un servidor de propósito especial 19, a la red informática 18, la estación de tierra 15, el satélite 13, un dispositivo Iridium, a un expansor E/S inteligente 50, y a un sistema de hardware de telemetría vehicular.

Sistema de hardware de telemetría vehicular

Refiriéndonos ahora a la figura 2a de los dibujos, se ilustra un sistema de hardware de telemetría vehicular generalmente indicado en 30. La porción a bordo generalmente incluye: un microprocesador de telemetría DTE (equipo de terminal de datos) 31; un microprocesador de comunicaciones por telemetría inalámbrica DCE (equipo de comunicaciones de datos) 32; un módulo GPS (sistema de posicionamiento global) 33; un acelerómetro 34; una memoria no volátil 35; y la provisión de una interfaz OBD (diagnóstico a bordo) 36 para la comunicación 43 con un bus de comunicaciones de red del vehículo 37.

La porción vehicular residente 42 generalmente incluye: el bus de comunicaciones de red del vehículo 37; el ECM (módulo de control electrónico) 38; el PCM (módulo de control del tren de potencia) 40; las ECU (unidades de control electrónico) 41; y otros ordenadores de control/monitorización de ordenadores y microcontroladores 39.

Si bien se describe que el sistema tiene una porción a bordo 30 y una porción vehicular residente 42, también se entiende que esto podría ser un sistema vehicular residente completo o un sistema a bordo completo.

El microprocesador de telemetría DTE 31 está interconectado con la interfaz OBD 36 para la comunicación con el bus de comunicaciones de red 37 del vehículo. El bus de comunicaciones de la red del vehículo 37 a su vez se conecta para la comunicación con el ECM 38, los ordenadores de control/monitorización del motor y microcontroladores 39, el PCM 40, y la ECU 41.

El microprocesador de telemetría DTE 31 tiene la capacidad a través de la interfaz OBD 36 cuando está conectado al bus de comunicaciones de la red del vehículo 37 para monitorizar y recibir datos del vehículo e información de los componentes del sistema vehicular residente para su posterior procesamiento.

Como un breve ejemplo no limitativo de una primera categoría de datos e información de vehículos telemáticos sin procesar, la lista puede incluir, pero no se limita a: un VIN (número de identificación del vehículo), lectura del odómetro actual, velocidad actual, RPM del motor, tensión de la batería, temperatura del anticongelante, nivel de refrigerante del motor, posición del pedal del acelerador, posición del pedal del freno, varios DTC específicos del fabricante del vehículo (códigos de diagnóstico de problemas), presión de los neumáticos, nivel de aceite, estado del airbag, indicación del cinturón de seguridad, datos de control de emisiones, temperatura del motor, presión del colector de admisión, datos de transmisión, información de frenado, indicaciones de flujo de masa de aire y nivel de combustible. Además, se entiende que la cantidad y el tipo de datos e información del vehículo sin procesar cambiarán de un fabricante a otro y evolucionarán con la introducción de tecnología vehicular adicional.

Continuando ahora con el microprocesador de telemetría DTE 31, además está interconectado para la comunicación con el microprocesador de comunicaciones de telemetría inalámbrica del DCE 32. En una realización de la invención, un ejemplo del microprocesador de comunicaciones de telemetría inalámbrica del DCE 32 es un Leon 100 disponible comercialmente por parte de u-blox Corporation. El Leon 100 proporciona capacidad y funcionalidad de comunicaciones móviles al sistema de hardware de telemetría vehicular 30 para enviar y recibir datos hacia/desde un sistema remoto 44. Un sitio remoto 44 podría ser otro vehículo o una estación terrestre. La estación terrestre puede incluir uno o más servidores de propósito especial 19 conectados a través de una red informática 18 (consulte la figura 1). Además, la estación terrestre puede incluir software de aplicación informática para la adquisición de datos, análisis, y envío/recepción de comandos hacia/desde el sistema de hardware de telemetría vehicular 30. El microprocesador de telemetría DTE 31 también está interconectado para la comunicación con el módulo GPS 33. En una realización de la invención, un ejemplo del módulo GPS 33 es un Neo-5 disponible comercialmente por parte de u-blox Corporation. El Neo-5 proporciona la capacidad y la funcionalidad del receptor GPS al sistema de hardware de telemetría vehicular 30. El módulo GPS 33 proporciona las coordenadas de latitud y longitud como una segunda categoría de datos e información telemáticos sin procesar.

El microprocesador de telemetría DTE 31 está además interconectado con una memoria externa no volátil 35. En una realización de la invención, un ejemplo de la memoria 35 es un almacenamiento de memoria no volátil de 32 MB disponible comercialmente por parte de Atmel Corporation. La memoria 35 de la presente invención se usa para registrar datos sin procesar.

El microprocesador de telemetría DTE 31 está además interconectado para la comunicación con un acelerómetro 34. Un acelerómetro (34) es un dispositivo que mide la aceleración física que experimenta un objeto. Modelos de acelerómetros individuales y de múltiples ejes están disponibles para detectar la magnitud y la dirección de la aceleración, o fuerza g, y el dispositivo también se puede usar para detectar la orientación, la aceleración coordinada, la vibración, los choques, y caídas. El acelerómetro 34 proporciona estos datos e información como una tercera categoría de datos de telemáticas sin procesar.

En una realización de la invención, un ejemplo de un acelerómetro de múltiples ejes (34) es el sensor de movimiento MEMS LIS302DL disponible comercialmente por parte de STMicroelectronics. El circuito integrado LIS302DL es un acelerómetro lineal de tres ejes ultracompacto de baja potencia que incluye un elemento de detección y una interfaz IC que puede tomar la información del elemento de detección y proporcionar los datos de aceleración medidos a otros dispositivos, tal como un microprocesador de telemetría DTE (31), a través de una interfaz en serie I2C/SPI (Circuito Inter-Integrado) (Interfaz Periférica en Serie). El circuito integrado LIS302DL tiene un rango de escala completa seleccionable por el usuario de -2 g y -8 g, umbrales programables, y es capaz de medir aceleraciones con una velocidad de datos de salida de 100 Hz o 400 Hz.

En una realización de la invención, el microprocesador de telemetría DTE 31 también incluye una cantidad de memoria interna para almacenar el firmware que se ejecuta en parte, métodos para operar y controlar el sistema general de hardware de telemetría vehicular 30. Además, el microprocesador 31 y el firmware registran datos, mensajes de formato, reciben mensajes, y convierten o reformatean mensajes. En una realización de la invención, un ejemplo de un microprocesador de telemetría DTE 31 es un microcontrolador PIC24H disponible comercialmente por parte de Microchip Corporation.

Refiriéndonos ahora a la figura 2b de los dibujos, se ilustra un sistema de hardware de telemetría vehicular generalmente indicado en 30 también comunicándose con al menos un expansor E/S inteligente 50. En esta realización, el sistema de hardware de telemetría vehicular 30 incluye una interfaz de mensajería 53. La interfaz de mensajería 53 está conectada al microprocesador de telemetría DTE 31. Además, el bus privado 55 puede conectar una interfaz de mensajería 53 en un expansor E/S inteligente 50. El bus privado 55 permite que se envíen y reciban mensajes entre el sistema de hardware de telemetría del vehículo 30 y el expansor E/S inteligente, o una pluralidad de expansores E/S (no mostrados). El sistema de hardware de expansión E/S inteligente 50 también incluye un microprocesador 51 y una memoria 52. Alternativamente, el sistema de hardware de expansión E/S inteligente 50 incluye un microcontrolador 51. Un microcontrolador incluye una CPU, RAM, ROM y periféricos. Los expertos en la técnica apreciarán que el término procesador contempla un microprocesador y una memoria o un microcontrolador en todas las realizaciones del hardware descrito (sistema de hardware de telemetría del vehículo 30, sistema de hardware de expansión E/S inteligente 50, módulo Bluetooth 45 (figura 2c) y baliza Bluetooth 21 (figura 2c)). El microprocesador 51 también está conectado a la interfaz de mensajería 53 y la interfaz configurable de múltiples dispositivos 54. En una realización de la invención, un microcontrolador 51 es un dispositivo LPC1756 ARM Cortec-M3 de 32 bits con hasta 512 KB de memoria de programa y 64 KB de SRAM. El LPC1756 también incluye cuatro UART, dos canales CAN 2.0B, un convertidor analógico a digital de 12 bits y un convertidor digital a analógico de 10 bits. En una realización alternativa, el sistema de hardware 50 del expansión E/S inteligente puede incluir hardware de texto a voz y firmware asociado (no ilustrado) para la salida de audio de un mensaje a un operador de un vehículo 11.

El microprocesador 51 y la memoria 52 cooperan para monitorizar al menos un dispositivo 60 (un dispositivo 62 y una interfaz 61) que se comunican 56 con el expansor E/S inteligente 50 a través de la interfaz configurable de múltiples dispositivos 54. Los datos y la información del dispositivo 60 pueden proporcionarse a través de la interfaz de mensajería 53 al sistema de hardware de telemetría vehicular 30, donde los datos y la información se conservan en el registro de datos de telemáticas sin procesar. Los datos y la información de un dispositivo 60 asociados con un expansor E/S inteligente proporcionan la 4a categoría de datos sin procesar del expansor y pueden incluir, pero no se limita a, datos de tráfico, horas de datos de servicio, datos de comunicación de campo cercano, tal como la identificación del conductor, datos del sensor del vehículo (distancia, tiempo, cantidad de material (sólido, líquido), datos del peso de la báscula de camiones, datos de distracción del conductor, datos del trabajador remoto, luces de advertencia del autobús escolar, y puertas abiertas/cerradas.

Refiriéndonos ahora a las figuras 2C, 2D y 2e, hay tres realizaciones alternativas relacionadas con el módulo Bluetooth 45 y la baliza Bluetooth 21 para monitorizar y recibir la 5a categoría de datos de baliza sin procesar. El módulo Bluetooth 45 incluye un microprocesador 142, una memoria 144 y un módulo de radio 146. El microprocesador 142, la memoria 144 y el firmware asociado proporcionan monitorización de los datos y la información de la baliza Bluetooth y la posterior comunicación de los datos de la baliza Bluetooth, ya sea directa o indirectamente a través de un expansor E/S inteligente 50, a un sistema de hardware de telemetría vehicular 30.

En una realización, el módulo Bluetooth 45 es integral con el sistema de hardware de telemetría vehicular 30. Los datos y la información se comunican 130 directamente desde la baliza Bluetooth 21 al sistema de hardware de telemetría vehicular 30. En una realización alternativa, el módulo Bluetooth 45 es integral con el expansor E/S inteligente. Los datos y la información se comunican 130 directamente al expansor E/S inteligente 50 y luego a través de la interfaz de mensajería 53 al sistema de hardware de telemetría vehicular 30. En otra realización alternativa, el módulo Bluetooth 45 incluye una interfaz 148 para comunicación 56 a la interfaz configurable de múltiples dispositivos 54 del expansor E/S inteligente 50. Los datos y la información se comunican 130 directamente al módulo Bluetooth 45, luego se comunican 56 al expansor E/S inteligente y finalmente se comunican 55 al sistema de hardware de telemetría vehicular 30.

Los datos y la información de una baliza Bluetooth 21 proporcionan la 5a categoría de datos de telemáticas sin procesar y pueden incluir datos e información sobre un objeto asociado con una baliza Bluetooth 21. Estos datos e información incluyen, pero no se limitan a, datos de aceleración del objeto, datos de temperatura del objeto, datos del nivel de batería, datos de presión del objeto, datos de luminancia de objetos y datos de sensores de objetos definidos por el usuario. Esta 5a categoría de datos puede usarse para indicar daños a un artículo o una condición peligrosa a un artículo.

Entorno analítico de telemetría vehicular

Refiriéndonos ahora a las figuras 3, 4 y 5, el entorno analítico de telemetría vehicular se describe con más detalle. El mapa 50 ilustra una serie de vehículos 11 (A a K) que operan en tiempo real. Por ejemplo, en la actualidad, Geotab tiene aproximadamente 500.000 dispositivos Geotab GO que operan en 70 países y comunican múltiples registros complejos de datos de telemáticas sin procesar al servidor de propósito especial 19. Cada uno de los vehículos 11 tiene al menos un sistema de hardware de telemetría vehicular 30 instalado y operativo con el vehículo 11. Alternativamente, algunos o todos los vehículos 11 pueden incluir además un expansor E/S inteligente 50 que se comunica con un sistema de hardware de telemetría vehicular 30. El expansor E/S inteligente 50 puede incluir además dispositivos 60 que se comunican con el expansor E/S inteligente 50 y el sistema de hardware de telemetría vehicular 30. Alternativamente, un módulo Bluetooth 45 puede incluirse con uno de los sistemas de hardware de telemetría vehicular 30, el dispositivo 60, o el expansor E/S inteligente 50. Cuando se incluye un módulo Bluetooth 45, entonces las balizas Bluetooth 21 pueden comunicar más datos con el módulo Bluetooth 45. Colectivamente, estas realizaciones alternativas y diferentes configuraciones de hardware especializado generan en tiempo real una gran cantidad de datos de telemáticas sin procesar. El sistema de hardware de telemetría vehicular 30 es capaz de comunicar la gran cantidad de datos de telemáticas sin procesar a través de la red 18 a otros servidores de propósito especial 19 y dispositivos informáticos 20. La comunicación de la gran cantidad de datos de telemáticas sin procesar puede producirse en intervalos predefinidos. La comunicación también puede activarse debido a un evento tal como un accidente. La comunicación puede ser periódica o aperiódica. La comunicación también puede ser solicitada por un comando enviado desde un servidor de propósito especial 19 o un dispositivo informático 20. Cada vehículo 11 proporcionará un registro de datos sin procesar de categoría 1 a través del sistema de hardware de telemetría vehicular 30. Entonces, dependiendo de la configuración específica previamente descrita, cada vehículo 11 puede incluir además en un registro, al menos uno de datos de telemáticas sin procesar de categoría 2, de categoría 3, de categoría 4 y de categoría 5 a través del sistema de hardware de telemetría vehicular 30.

Varios servidores de propósito especial 19 también forman parte del entorno analítico de telemetría vehicular y se comunican a través de la red 18. Los servidores de propósito especial 19 pueden ser un servidor, más de un servidor, distribuido, basado en la nube o dividido en porciones en tipos específicos de funcionalidad, tal como un servidor de información complementario 52, servidores externos de terceros, un servidor de almacenamiento y reenvío 54 y un servidor de análisis 56. Los dispositivos informáticos 20 también pueden comunicarse con los servidores de propósito especial 19 a través de la red 18.

En una realización de la invención, los registros de datos de telemáticas sin procesar se comunican desde una pluralidad de vehículos en tiempo real y son recibidos por un servidor 54 con capacidad de almacenamiento y reenvío tal como grandes cantidades de datos de telemáticas sin procesar (RTbD). En una realización de la invención, un constructor de grandes cantidades de datos de telemáticas analíticas 55 está dispuesto con el servidor 54. El constructor de grandes cantidades de datos de telemáticas analíticas 55 recibe las grandes cantidades de datos de telemáticas sin procesar (RTbD) directa o indirectamente desde el servidor 54. El constructor de grandes cantidades de datos de telemáticas analíticas 55 tiene acceso a datos complementarios (SD) ubicados directa o indirectamente en un servidor de información complementaria 52. Alternativamente, los datos complementarios (SD) pueden disponerse con el servidor 54. El constructor de grandes cantidades de datos de telemáticas analíticas 55 transforma las grandes cantidades de datos de telemáticas (RTbD) en grandes cantidades de datos de telemáticas analíticas (ATbD) para su uso con un servidor 56 que tiene capacidad analítica de grandes cantidades de datos 56. Un ejemplo de tal capacidad es la tecnología Google™ BigQuery. Entonces, los dispositivos informáticos 20 pueden acceder a la gran cantidad de datos de telemáticas analíticas (ATbD) en tiempo real para realizar consultas de gestión de flotas e informes. El servidor 56 con capacidad analítica puede ser un único servidor de análisis o una pluralidad de servidores de análisis 56a, 56b y 56c.

Un ejemplo de la transformación de grandes cantidades de datos de telemáticas sin procesar (RTbD) en grandes cantidades de datos de telemáticas analíticas (ATbD) es para realizar consultas e informar acerca de un fallo de comunicación del dispositivo móvil con respecto a una red de comunicaciones. La gran cantidad de datos de telemáticas sin formato (RTbD) contiene al menos una ubicación GPS del dispositivo móvil y el vehículo asociado (información de latitud y longitud). La información complementaria en forma de datos complementarios (SD) puede luego agregar una ubicación particular del vehículo (carretera o calle o dirección) en un mapa como se ilustra en la figura 4 con respecto a los iconos del vehículo A a K inclusive. Además, los datos complementarios (SD) también pueden aplicarse para ilustrar diferentes zonas de comunicación o áreas de comunicación 51 en el mapa 50. Esto permite una correlación entre la ubicación de un vehículo o dispositivo móvil en el mapa con respecto a la zona de comunicación o área 51. Si un dispositivo móvil tiene un problema de comunicación, la zona de comunicación o área 51 puede identificarse a partir de un análisis de las grandes cantidades de datos.

Constructor de grandes cantidades de datos de telemáticas analíticas

Refiriéndonos ahora a la figura 6a, se describe una realización del constructor de grandes cantidades de datos de telemáticas analíticas 55. Los expertos en la materia apreciarán que el constructor de grandes cantidades de datos de telemáticas analíticas 55 puede ser un dispositivo independiente con un microprocesador, memoria, firmware o software con capacidad de comunicaciones. Alternativamente, el constructor de grandes cantidades de datos de telemáticas analíticas 55 puede ser integral con un servidor de propósito especial, por ejemplo, un servidor de almacenamiento y reenvío 54. Alternativamente, el constructor de grandes cantidades de datos de telemáticas analíticas 55 puede estar asociado o ser integral con un sistema de hardware de telemetría del vehículo 30. Alternativamente, la funcionalidad del constructor de grandes cantidades de datos de telemáticas analíticas 55 puede ser un recurso basado en la nube. Alternativamente, puede haber uno o más constructores analíticos de grandes cantidades de datos de telemáticas 55 para transformar en tiempo real las grandes cantidades de datos de telemáticas sin procesar (RTbD) en grandes cantidades de datos de telemáticas analíticas (ATbD).

El constructor analítico de grandes cantidades de datos de telemáticas 55 recibe en tiempo real las grandes cantidades de datos de telemáticas (RTbD) en un segregador de datos. La gran cantidad de datos de telemáticas sin procesar (RTbD) es un registro mixto de datos de telemáticas sin procesar e incluye datos sin procesar de vehículo de categoría 1 y al menos uno de datos de telemáticas sin procesar de categoría 2, categoría 3, categoría 4 o categoría 5. Los expertos en la materia apreciarán que puede haber más o menos de cinco categorías de datos de telemáticas sin procesar. El segregador de datos procesa cada registro de datos de telemáticas sin procesar e identifica o separa los datos para preservar los datos y alterar los datos en tiempo real. Esto se lleva a cabo categoría por categoría, o alternativamente, sobre una base de subcategoría. Los datos conservados se proporcionan en el formato sin procesar a un amalgamador de datos. Los datos alterados se proporcionan a un modificador de datos. El modificador de datos obtiene datos complementarios (SD) para complementar y modificar los datos modificados con información adicional. Los datos complementarios (SD) pueden ser residentes del constructor de grandes cantidades de datos de telemáticas analíticas 55 o externos, por ejemplo, ubicado en al menos un servidor de información suplementaria 52, o ubicado en al menos un servidor de almacenamiento y reenvío 54 o en la nube y puede ser distribuido. El modificador de datos luego proporciona los datos modificados y los datos complementarios al amalgamador de datos. El amalgamador de datos vuelve a montar o formatea los datos preservados, altera los datos y los datos complementarios (SD) para construir las grandes cantidades de datos analíticos telemáticos (ATbD) en tiempo real. La gran cantidad de datos de telemáticas analíticas (ATbD) pueden comunicarse en tiempo real, transmitirse en tiempo real o almacenarse en tiempo real para su posterior análisis de gestión de flotas en tiempo real. En una realización de la invención, las grandes cantidades de datos de telemáticas (ATbD) se comunican y se transmiten en tiempo real a un servidor de análisis 56 que tiene acceso a la tecnología Google BigQuery.

Refiriéndonos ahora a la figura 6b, se describe otra realización del constructor de grandes cantidades de datos de telemáticas analíticas 55. En esta realización, el segregador de datos procesa la gran cantidad de datos de telemáticas sin procesar (RTbD) en una pluralidad de datos distintos (1, 2, 3, n) tipos o grupos basados en las categorías. La pluralidad de datos de preservación se proporciona luego al amalgamador de datos para ensamblarlos con los datos modificados para ensamblarlos en la gran cantidad de datos de telemáticas analíticas (ATbD).

Refiriéndonos ahora a la figura 6c, se describe otra realización del constructor de grandes cantidades de datos de telemáticas analíticas 55. En esta realización, el segregador de datos procesa la gran cantidad de datos de telemáticas sin procesar (RTbD) para conservar los datos (categoría 1) y una pluralidad de datos distintos (A, B, C, n) tipos o grupos basados en las categorías (2, 3, 4 y 5). Por ejemplo, una categoría puede ser datos del motor que están en un formato de máquina. Este formato de máquina puede traducirse a un formato legible por humanos. Otro ejemplo puede ser otra categoría de datos GPS en un formato de máquina de coordenadas de latitud y longitud. Este formato de máquina diferente puede aumentarse con información legible por humanos. Los tipos de datos modificados se proporcionan al modificador de datos y el modificador de datos obtiene una pluralidad de tipos de datos complementarios (SD) correspondientes (A, B, C, n). El modificador de datos luego altera los tipos de datos modificados con los tipos de datos complementarios correspondientes. Los datos de preservación y la pluralidad de datos modificados se proporcionan al amalgamador de datos para ensamblarlos en la gran cantidad de datos de telemáticas analíticas (ATbD).

Las personas expertas en la técnica aprecian que puede haber una información de preservación, un dato alterado, al menos un dato preservado, al menos un dato alterado en diferentes combinaciones entre el segregador de datos y el amalgamador de datos.

Constructor de grandes cantidades de datos de telemáticas analíticas y memoria intermedias activas

Otra realización de la invención que incluye al menos una memoria intermedia activa o una cola de bloqueo se describe con referencia a las figuras 7a, 7b y 7c. Una primera memoria intermedia activa (ver la figura 7a) puede disponerse con el constructor de grandes cantidades de datos de telemáticas analíticas 55. La primera memoria intermedia activa puede retener temporalmente al menos un dato alterado. En una realización de la invención, la primer memoria intermedia activa se dispone entre el segregador de datos y el amalgamador de datos. La primera memoria intermedia activa asiste al constructor de grandes cantidades de datos de telemáticas analíticas 55. Por ejemplo, el procesamiento de las grandes cantidades de datos de telemáticas sin procesar (RTbD) en el segregador de datos puede ser a una tasa más constante en contraste con el procesamiento de los datos adicionales y los datos complementarios en el modificador de datos. Cuando se produce una diferencia en las tasas de procesamiento, o diferencias en el tiempo, la primera memoria intermedia activa puede suavizar cargas de datos pesadas intermitentes y minimizar cualquier impacto de la demanda máxima en la disponibilidad y capacidad de respuesta del constructor de grandes cantidades de datos de telemáticas analíticas 55 y servicios externos y adquisición de datos complementarios.

Alternativamente, una segunda memoria intermedia activa doble o doble cola de bloqueo (ver la figura 7b) también puede disponerse con el constructor de grandes cantidades de datos de telemáticas analíticas 55. La segunda memoria intermedia activa doble puede retener temporalmente la gran cantidad de datos de telemáticas analíticas (ATbD). Esto puede ocurrir cuando una solicitud de comunicación o transmisión falla debido a problemas de la red o excepciones con el servidor de análisis 56. La gran cantidad de datos de telemáticas analíticas (ATbD) se mantiene en la segunda memoria intermedia activa doble, de modo que los datos están disponibles y se comunican con éxito al servidor de análisis 56 en un orden y secuencia en tiempo real. En una realización de la invención, la segunda memoria intermedia activa doble se desecha después del amalgamador de datos.

Alternativamente, otra realización con memorias intermedias activas se ilustra en la figura 7c e incluye tanto la primera memoria intermedia activa como la segunda memoria intermedia activa doble.

Datos complementarios, datos de traducción y datos de aumento

Otro conjunto de realizaciones de la invención se ilustra con clasificaciones de ejemplo o grupos de datos complementarios como se muestra con referencia a las figuras 8a, 8b y 8c. El segregador de datos procesa la gran cantidad de datos de telemáticas sin procesar (RTbD) en tres tipos o flujos de datos. El primer tipo de datos es preservar los datos que se pasan directamente al amalgamador de datos. Un segundo tipo de datos es alterar los datos traducidos y el tercer tipo de datos es alterar los datos de aumento. El modificador de datos para esta realización puede ser al menos un modificador de datos.

La modificación de los datos de traducción requiere datos de traducción. El modificador de datos obtiene datos complementarios (SD) en forma de datos de traducción (TD) para modificar los datos de traducción alterados. Los datos de traducción (TD) pueden residir en el constructor analítico de datos grandes de datos de telemáticas 55 o externo, por ejemplo, ubicado en al menos un servidor de traducción 53.

Los datos de aumento alterados requieren datos de aumento (AD). El modificador de datos obtiene datos complementarios (SD) en forma de datos de aumento para modificar los datos de aumento alterados. Los datos de aumento (AD) pueden ser residentes del constructor analítico de datos grandes de datos de telemáticas 55 o externos, por ejemplo, ubicado en al menos un servidor de aumento 57. El amalgamador de datos vuelve a montar o formatea los datos preservados, se modificaron los datos de traducción y se modificaron los datos de aumento para construir la gran cantidad de datos de telemáticas analíticas (ATbD). La gran cantidad de datos de telemáticas analíticas (ATbD) pueden comunicarse, transmitirse en tiempo real o almacenarse en tiempo real para su posterior análisis de gestión de flotas en tiempo real.

La realización en la figura 8b es similar a la realización en la figura 8a, pero el constructor de grandes cantidades de datos de telemáticas analíticas 55 solo proporciona datos de traducción y datos de preservación en la transformación a grandes cantidades de datos de telemáticas analíticas (ATbD). La realización en la figura 8c también es similar a la realización en la figura 8a, pero el constructor analítico de grandes cantidades de datos de telemáticas analíticas 55 solo proporciona datos de aumento y preservación en la transformación a grandes cantidades de datos de telemáticas analíticas (ATbD). Las realizaciones alternativas de la figura 8b y la figura 8c son ejemplos de constructores de grandes cantidades de datos de telemáticas analíticas 55 dedicados a flujos particulares y categorías de grandes cantidades de datos de telemáticas sin procesar (RTbD). Los expertos en la materia apreciarán que el constructor de grandes cantidades de datos de telemáticas analíticas puede procesar datos preservados, datos alterados, o una combinación de datos preservados y datos alterados.

Otro conjunto de realizaciones de la invención incluye categorías de ejemplo de datos complementarios y memorias intermedias activas. Esto se describe con referencia a las figuras 9a, 9b y 9c. El segregador de datos procesa la gran cantidad de datos de telemáticas sin procesar (RTbD) en tres tipos de datos. El primer tipo de datos es preservar los datos que se pasan directamente al amalgamador de datos. Un segundo tipo de datos es alterar los datos traducidos y el tercer tipo de datos es alterar los datos de aumento. Se proporciona al menos una memoria intermedia activa al generador de grandes cantidades de datos temáticos analíticos 55 para almacenar en memoria intermedia uno o ambos de los datos de traducción alterados y los datos de aumento alterados. El modificador de datos obtiene datos complementarios en forma de datos de traducción (TD) para enmendar los datos modificados de traducción y los datos complementarios (SD) en forma de datos de aumento (AD) para modificador los datos de aumento alterados. El amalgamador de datos vuelve a montar o formatea los datos preservados, los datos de traducción modificados y los datos de aumento modificados para construir la gran cantidad de datos de telemáticas analíticas (ATbD) que luego se pueden comunicar o transmitir en tiempo real o almacenar en tiempo real para el posterior análisis de la gestión de la flota en tiempo real.

Se describe un ejemplo con respecto a los datos de GPS encontrados en las grandes cantidades de datos de telemáticas sin procesar (RTbD). Los datos de GPS contienen una indicación de latitud y longitud de un vehículo o dispositivo móvil. Los datos de GPS se pueden transformar en grandes cantidades de datos de telemáticas (ATbD) de dos maneras. Los datos de GPS se pueden transformar en una ubicación tal como una carretera, autopista, calle 0 dirección. Luego, un icono que representa el vehículo puede asociarse con un mapa móvil 50 para proporcionar una ubicación del vehículo. Los datos de GPS también pueden transformarse en un área o zona de red o célula 51 o áreas o zonas múltiples 51 (consulte la figura 4). Entonces, el icono que representa el vehículo también puede estar asociado con un área de red o zona 51 en el mapa en movimiento 50.

La realización en la figura 9b es similar a la realización en la figura 9a, pero el constructor de grandes cantidades de datos de telemáticas analíticas 55 solo proporciona datos de traducción y datos de preservación en la transformación a grandes cantidades de datos de telemáticas analíticas (ATbD). La realización en la figura 9c también es similar a la realización en la figura 9a, pero el constructor analítico de grandes cantidades de datos de telemáticas analíticas 55 proporciona datos de aumento y preservación en la transformación a grandes cantidades de datos de telemáticas analíticas (ATbD). Estas realizaciones alternativas de la figura 9b y la figura 9c son también ejemplos de constructores de grandes cantidades de datos de telemáticas analíticas 55 dedicados a flujos particulares y categorías de grandes cantidades de datos de telemáticas sin procesar (RTbD).

Las realizaciones ilustradas en las figuras 10a, 10b y 10c son similares a las realizaciones en las figuras 9a, 9b y 9c e incluyen además la primera memoria intermedia activa y la segunda memoria intermedia activa doble. La primera memoria intermedia activa está dispuesta en el constructor de grandes cantidades de datos de telemáticas analíticas 55 es intermedio al segregador de datos y al amalgamador de datos. La segunda memoria intermedia activa doble se desecha después del amalgamador de datos.

Constructor de grandes cantidades de datos de telemáticas analíticas y flujo de datos de ejemplo

La figura 11 ilustra una realización de la invención con un flujo de datos de ejemplo a través del constructor de grandes cantidades de datos de telemáticas analíticas 55. En este ejemplo, las grandes cantidades de datos de telemáticas sin procesar (RTbD) incluyen datos de categoría 1 en dos subcategorías. La primera subcategoría incluye datos de depuración y datos del número de identificación del vehículo (VIN). La segunda subcategoría incluye datos específicos del motor. Los datos de la categoría 2 incluyen datos de GPS y los datos de la categoría 3 incluyen datos del acelerómetro.

La gran cantidad de datos de telemáticas sin procesar (RTbD), incluyendo la categoría 1 (y subcategorías), 2, y 3 se proporciona al segregador de datos. El segregador de datos identifica los datos preservados de la gran cantidad de datos de telemáticas sin procesar (RTbD). Los datos de conservación incluyen las porciones de los datos de la categoría 1 (datos de depuración y datos del número de identificación del vehículo (VIN)) y los datos del acelerómetro de la categoría 3. Esta información de preservación se proporciona directamente al amalgamador de datos.

El segregador de datos también identifica alterar los datos traducidos e incluye una porción de los datos de categoría 1 (datos específicos del motor). Los datos de traducción (TD) requeridos incluyen al menos uno de los datos del código de fallo, datos de código de fallo estándar, datos de código de fallo no estándar, descripciones de error, descripciones de avisos e información diagnóstica. El modificador de datos luego proporciona los datos de traducción alterados y los datos de traducción (TD) en forma de datos de motor modificados.

El segregador de datos también identifica los datos de aumento alterados e incluye los datos de categoría 2 (datos de GPS). Los datos de argumentación (AD) requeridos incluyen al menos uno de los datos de código postal, datos de la dirección de la calle, dato de contacto, datos de la zona de red, datos del área de red, o datos de célula de red. El modificador de datos luego proporciona los datos de aumento alterados y los datos de aumento en forma de datos de GPS modificados.

El amalgamador de datos luego ensambla o formatea y proporciona la gran cantidad de datos de telemáticas analíticas (ATbD) en tiempo real. La gran cantidad de datos de telemáticas analíticas (ATbD) incluye datos de depuración, datos del número de identificación del vehículo (VIN), datos del acelerómetro, datos del motor, al menos uno de los datos del código de fallo, datos de código de fallo estándar, datos de código de error no estándar, descripciones de error, descripciones de advertencia, información de diagnóstico, datos de GPS y al menos uno de los datos del código postal, datos del código postal, datos del domicilio, o datos de contacto.

Categorías de datos, datos de ejemplo y datos complementarios

La Tabla 1 proporciona una lista de ejemplo de categorías de datos de telemáticas sin procesar, datos de ejemplo para cada categoría y una indicación de cualquier dato complementario requerido por cada categoría. La categoría 1 se ilustra como un par de subcategorías 1a y 1b, pero también puede organizarse en dos categorías separadas. La Tabla 1 es un ejemplo donde los datos de telemáticas sin procesar incluyen diferentes grupos o tipos de datos similares en forma de subconjuntos de datos.

T l 1: D in r r m n r i n m l .

continuación

Los expertos en la técnica apreciarán otras categorías, o subcategorías de grandes cantidades de datos de telemáticas sin procesar (RTbD) y otras categorías o subcategorías de datos complementarios (SD) que pueden incluirse y transformarse en grandes cantidades de datos de telemáticas analíticas (ATbD) por parte del constructor de grandes cantidades de datos de telemáticas analíticas 55 de la presente invención.

Representación de la máquina de estado

Refiriéndonos ahora a las figuras 12a, 12b y 12c, se describe una representación de la máquina de estado de la lógica asociada con el constructor de grandes cantidades de datos analíticos 55. Hay cuatro estados en la lógica que operan simultáneamente y en paralelo. Además, puede haber múltiples instancias de cada estado. El estado inicial es el estado de segregador de datos. La lógica de estado del segregador de datos es filtrar, identificar y separar la gran cantidad de datos de telemáticas sin procesar (RTbD) para preservar los datos y alterarlos. El estado del segregador de datos espera la recepción de un registro o porción de la gran cantidad de datos de telemáticas sin procesar (RTbD). Al recibirlos, el segregador de datos procesa la gran cantidad de datos de telemáticas sin procesar (RTbD) en al menos una ruta de datos de preservación o al menos una ruta de datos alternativa. La gran cantidad de datos de telemáticas sin procesar (RTbD) en la al menos una ruta de datos de preservación se proporciona opcionalmente a una primera memoria intermedia activa o directamente al estado del amalgamador de datos. La gran cantidad de datos de telemáticas sin formato (RTbD) en la ruta de modificación de datos se proporciona opcionalmente a una primera memoria intermedia activa o directamente al estado del modificador de datos. Entonces, el estado del segregador de datos espera la recepción del siguiente registro o porción de la gran cantidad de datos de telemáticas (RTbD).

En una realización de ejemplo de la invención, las categorías 1a y 3 son datos de preservación y se proporcionan al estado del amalgamador de datos. La categoría 1b, 2, 4 y 5 son datos alterados y se proporcionan al estado del modificador de datos.

La lógica del estado del modificador de datos es identificar cada categoría de datos alterados y asociar una categoría de datos complementarios con cada categoría de datos alterados y proporcionar datos modificados (datos alterados y datos complementarios) al estado del amalgamador de datos. El estado del modificador de datos espera la recepción de una porción de la gran cantidad de datos de telemáticas sin procesar (RTbD) que se identifica como datos alterados. Entonces, el estado del modificador de datos obtiene datos complementarios para los datos alterados. Esto se produce para cada categoría de datos alterados y datos complementarios asociados. Finalmente, el estado del modificador de datos proporciona los datos modificados (cada alteración y cada dato complementario) al estado del amalgamador de datos.

En una realización de la invención, el estado del modificador de datos tiene dos subestados, el estado de los datos traducidos y el estado de los datos aumentados. El estado de los datos traducidos obtiene los datos traducidos para categorías particulares de datos modificados que requieren una traducción. El estado de los datos de aumento obtiene datos de aumento para categorías particulares de datos de modificación que requieren aumento. Las personas expertas en la técnica apreciarán que otros subestados pueden agregarse al estado del modificador de datos.

En una realización de ejemplo de la invención, la categoría 2 requiere datos de aumento y categoría 1b, 4 y 5 requieren datos traducidos. Los datos de aumento de ejemplo y los datos de traducción se ilustran previamente en la Tabla 1.

La lógica del estado del amalgamador de datos es ensamblar, formatear o integrar los datos preservados, los datos alterados y los datos complementarios en la gran cantidad de datos de telemáticas analíticas (ATbD). El estado del amalgamador de datos recibe los datos conservados del segregador de datos y los datos modificados del estado del modificador de datos. Los datos conservados se procesan en el formato para la gran cantidad de datos de telemáticas analíticas (ATbD). La gran cantidad de datos de telemáticas analíticas (ATbD) en la ruta de datos de preservación se proporcionan opcionalmente a una segunda memoria intermedia doble activa o directamente al estado del amalgamador de datos.

La lógica del estado de transferencia de datos es comunicar o almacenar o transmitir la gran cantidad de datos de telemáticas analíticas (ATbD) a un servidor de análisis 56 o un recurso de computación en la nube. El estado de transferencia de datos recibe la gran cantidad de datos de telemáticas analíticas (ATbD) ya sea directamente del estado del amalgamador de datos o indirectamente de la segunda memoria intermedia activa doble. La gran cantidad de datos de telemáticas analíticas (ATbD) se proporcionan luego al servidor de análisis 56 o al recurso basado en computación en la nube.

Lógica de proceso y tareas

La lógica de proceso y las tareas de la presente invención se describen con referencia a las figuras 13a, 13b, 13c, 13d, 13e y 13f. La lógica de estado y las tareas del segregador de datos comienzan con la obtención en tiempo real de un registro de grandes cantidades de datos de telemáticas sin procesar (RTbD). El registro de grandes cantidades de datos de telemáticas sin procesar (RTbD) se segrega en al menos una categoría de datos de preservación y al menos una categoría de datos de modificación. En una realización de la invención, hay más de una categoría de datos de preservación, y ninguna categoría de alteración, etc. Los datos de preservación están disponibles para el amalgamador de datos. El al menos un dato alterado se pone a disposición del modificador de datos. La lógica de proceso y tareas pueden escalarse automáticamente según sea necesario para el registro de grandes cantidades de datos de telemáticas sin procesar (RTbD). La lógica de estado y las tareas del segregador de datos pueden ser procesamiento secuencial o procesamiento paralelo o una combinación de procesamiento secuencial y paralelo.

La lógica del proceso y las tareas para la lógica y las tareas del estado del modificador de datos comienzan con la obtención de al menos un dato alterado del segregador de datos. Para cada uno del al menos un dato alterado, se obtienen los datos complementarios correspondientes. Cada uno del al menos uno del dato alterado se modifica con los datos complementarios correspondientes para formar al menos uno dato modificado. El al menos un dato modificado se pone a disposición del modificador de datos. La lógica de proceso y las tareas pueden escalarse automáticamente según sea necesario para los datos modificados y/o los datos complementarios.

La lógica de proceso y las tareas para la lógica de estado del amalgamador de datos y las tareas comienzan obteniendo al menos un dato preservado del segregador de datos y al menos un dato modificado del modificador de datos. La al menos una información preservada y la al menos una información modificada se amalgaman para formar la gran cantidad de datos analíticos telemáticos. La lógica de proceso y las tareas pueden escalarse automáticamente según sea necesario, ya sea para el al menos un dato preservado y/o el al menos un dato modificado. La lógica de estado y las tareas del amalgamador de datos pueden ser procesamiento secuencial o procesamiento paralelo o una combinación de procesamiento secuencial y paralelo.

La lógica de proceso y las tareas para la lógica de estado de transferencia de datos y las tareas, comienzan con la obtención de la gran cantidad de datos analíticos telemáticos (ATbD) del amalgamador de datos. La gran cantidad de datos de telemáticas analíticas (ATbD) se comunica o transmite a un servidor analítico o a un recurso basado en la nube. La lógica de proceso y las tareas pueden escalarse automáticamente según se requiera para la gran cantidad de datos de telemáticas analíticas (ATbD).

Equilibrio de carga

Otra característica amplia de la presente invención se describe con referencia a las figuras 3, 6b, 7c, 12b, 13a, 13b, 13c, 13d, 13e y 13f. Como se ilustra en el mapa 50, muchos vehículos diferentes 11 pueden estar operativos en un momento dado en todo el mundo en muchas zonas horarias diferentes durante toda la monitorización, registro y comunicación de datos de telemáticas sin procesar a un constructor de grandes cantidades de datos de telemáticas analíticas 55 en tiempo real. Las categorías y el tipo de datos de telemáticas sin procesar (consulte la Tabla 1) también pueden variar mucho dependiendo de las configuraciones específicas de cada vehículo 11 (sistema de hardware de telemetría vehicular 30, expansores E/S inteligentes 50, dispositivos 60, módulos Bluetooth 45 y balizas Bluetooth 21 asociados con una pluralidad de objetos). Esto se traduce en una velocidad de grandes cantidades de datos única, tiempo, variedad y cantidad de datos de telemáticas sin procesar que colectivamente forman la gran cantidad de datos de telemáticas sin procesar (RTbD) que entran al segregador de datos del constructor de grandes cantidades de datos de telemáticas analíticas 55. Esto se denomina colectivamente como una carga de grandes cantidades de datos de telemáticas sin procesar (RTbD).

También hay muchos tipos diferentes de datos complementarios (SD) requeridos por el modificador de datos disponible en diferentes ubicaciones y fuentes remotas. Los datos complementarios (SD) también dependen de la porción o mezcla de la gran cantidad de datos de telemáticas sin procesar (RTbD). Esto se traduce en otra velocidad de grandes cantidades de datos única, tiempo, variedad y cantidad de datos complementarios (SD) (ver datos de aumento y datos de traducción de la Tabla 1) requeridos por el modificador de datos. Esto se conoce colectivamente como una carga de datos complementaria.

La comunicación o transmisión de grandes cantidades de datos de telemáticas analíticas (ATbD) a un servidor analítico 56 o un recurso basado en la nube también depende de la capacidad del servidor analítico 56 o de los recursos basados en la nube para recibir la gran cantidad de datos de telemáticas analíticas (ATbD). Esto resulta en otra velocidad única de grandes cantidades de datos, tiempo, variedad y disponibilidad para comunicar o transmitir la gran cantidad de datos de telemáticas analíticas (ATbD). Esto se conoce colectivamente como una carga analítica de datos de telemáticas (ATbD).

El resultado final es una pluralidad de desequilibrios potenciales para la carga, velocidad, variedad de tiempo y cantidad de datos de telemáticas sin procesar (RTbD), datos complementarios (SD) y grandes cantidades de datos de telemáticas analíticas (ATbD). Por lo tanto, el constructor de grandes cantidades de datos de telemáticas analíticas 55, máquina de estados finitos, proceso y tareas de la presente invención deben poder ocuparse en tiempo real de este desequilibrio en tiempo real.

En una realización de la invención, este desequilibrio es resuelto por la disposición única de los canales, filtros y tareas asociadas al constructor de grandes cantidades de datos de telemáticas analíticas 55. Esta disposición única permite equilibrar la carga y escalar cuando se producen desequilibrios en el sistema. Por ejemplo, los canales, los filtros y las tareas pueden aumentarse o disminuirse dinámicamente (instancias concurrentes) en función de la carga en tiempo real. Los datos están estandarizados en formatos específicos para cada uno de los estados finitos, lógica, recursos, procesos y tareas. Esto incluye el formato de grandes cantidades de datos de telemáticas sin procesar (RTbD), el formato de datos complementarios (SD), el formato de datos preservados, el formato de datos alterados, el formato de datos de aumento (AD), el formato de datos de traducción (TD) y el formato de grandes cantidades de datos analíticos telemáticos (ATbD). Además, se proporciona una estructura de canalización única para que el constructor de grandes cantidades de datos de telemáticas analíticas 55 equilibre la carga en el sistema. La gran cantidad de datos de telemáticas sin procesar entra al constructor de grandes cantidades de datos de telemáticas analíticas a través de un primer canal hacia el segregador de datos. El segregador de datos luego pasa los datos a través de al menos dos canales para preservar los datos y alterar los datos. La línea de datos de alteración puede incluir además canales adicionales (A, B, C, n). Los canales de datos alterados se introducen en el modificador de datos con los canales de datos complementarios (SD) correspondientes. Los canales de datos modificados y la fuente de datos de preservación en el amalgamador de datos y, finalmente, las grandes cantidades de datos de telemáticas analíticas (ATbD) se introducen en el canal de comunicación o transmisión. Esta arquitectura de canales específicos telemáticos permite ejecutar en paralelo y múltiples instancias del estado del segregador de datos, el estado del modificador de datos, el estado del amalgamador de datos y el estado de transmisión de datos permite al sistema repartir la carga y mejorar el rendimiento del constructor de grandes cantidades de datos analíticos telemáticos 55. Esto también ayuda a equilibrar el sistema en situaciones donde los datos, por ejemplo, la gran cantidad de datos de telemáticas sin procesar (RTbD) y los datos complementarios (SD) no están en la misma ubicación geográfica.

En otra realización de la invención, este desequilibrio se resuelve mediante la aplicación de la primera memoria intermedia activa y/o de la segunda memoria intermedia activa, ya sea en solitario o en combinación. La primera memoria intermedia activa maneja el desequilibrio entre la gran cantidad de datos de telemáticas sin procesar (RTbD) y los datos complementarios (SD). La segunda memoria intermedia activa maneja el posible desequilibrio al comunicar o transmitir la gran cantidad de datos de telemáticas analíticas (ATbD) a un servidor de análisis 56 o un recurso basado en la nube. Las memorias intermedias pueden escalar hacia arriba o hacia abajo dependiendo de las necesidades del constructor de grandes cantidades de datos de telemáticas analíticas 55.

En otra realización de la invención, este desequilibrio se resuelve mediante el diseño de la máquina de estados finitos, la lógica, los recursos, el proceso y las tareas del proceso a través de una consolidación de recursos de computación telemática única y específica.

El estado del segregador de datos, lógica, proceso y tareas se ocupan automáticamente de la escalabilidad de la gran cantidad de datos de telemáticas sin procesar (RTbD) y las tareas de procesamiento asociadas para filtrar los datos en datos preservados y datos alterados. Esto incluye tanto el escalado hacia arriba como hacia abajo dependiendo de la carga correspondiente requerida por la gran cantidad de datos de telemáticas sin procesar (RTbD) y la cantidad de procesamiento requerido para segregar porciones de los datos para los datos preservados o los datos alterados. Instancias adicionales del estado del segregador de datos, lógica, proceso y tareas se pueden iniciar o detener automáticamente de acuerdo con la carga, los requerimientos de demanda o comunicación.

El estado del modificador de datos, lógica, proceso y tareas se ocupan automáticamente de la escalabilidad con los datos complementarios (SD). Esto incluye tanto la ampliación como la reducción dependiente de la carga correspondiente requerida por los datos complementarios (SD) y la cantidad de procesamiento requerido para enmendar cada dato alterado. Instancias adicionales del estado del modificador de datos, lógica, proceso y tareas se pueden iniciar o detener automáticamente de acuerdo con la carga, los requerimientos de demanda o comunicación.

El estado del amalgamador de datos, el proceso lógico y las tareas se ocupan automáticamente de la escalabilidad con los datos preservados, los datos modificados y capacidad para comunicar o transmitir la gran cantidad de datos de telemáticas analíticas (ATbD) a un servidor de análisis 56 o recurso de computación basado en la nube.

Instancias adicionales del estado del amalgamador de datos, lógica, proceso y tareas se pueden iniciar o detener automáticamente de acuerdo con la carga, los requerimientos de demanda o comunicación.

El constructor de grandes cantidades de datos de telemáticas analíticas 55 permite una visión en tiempo real basada en las grandes cantidades de datos de telemáticas analíticas en tiempo real. Por ejemplo, los datos pueden aplicarse para monitorizar la cantidad de dispositivos Geotab GO que se conectan actualmente al servidor de propósito especial 19 y compararlos con la cantidad de dispositivos GO que se espera que estén conectados en cualquier momento durante el día; o ser capaz de utilizar la gran cantidad de datos de telemáticas analíticas en tiempo real para monitorizar los dispositivos GO que se conectan a su servidor de propósito especial 19 desde cada proveedor de red celular o satélite. Utilizando estos datos, los gerentes pueden determinar si un operador de red en particular tiene problemas para la notificación proactiva con clientes que pueden verse afectados por la interrupción del servicio.

Determinación de fallos de comunicación de red en tiempo real

El sistema de monitorización de fallos de comunicación de grandes cantidades de datos de telemáticas se describe a continuación con respecto a la figura 4 y la figura 11. Cada dispositivo móvil se comunica con el dispositivo de eliminación en forma de grandes datos de telemáticas sin procesar (RTbD). Estos datos incluyen datos de GPS que se identifican para su modificación. La modificación incluye datos de aumento en forma de códigos postales, direcciones de calles o nombres de contactos o direcciones para permitir asociar la ubicación de un vehículo en un mapa 50. La modificación también incluye datos de aumento en forma de áreas de red o zonas de red o células de red 51 para permitir asociar una ubicación de vehículo dentro de una red de comunicación y la superposición del área o zona o célula 51 en un mapa 50. En una realización de la invención, los datos de aumento son un número de identificación de célula utilizado para identificar una estación o sector transceptor base de una estación transceptora base dentro de un código de área de ubicación. El número de identificación de la célula corresponde a GSM, c DmA, UMTS, LTE, WiFi y otras formas de redes de comunicación. Además, los datos de aumento pueden incluir además códigos de red móvil y el número de identificación del portador u operador. Los números de identificación están disponibles en diferentes bases de datos y proveedores de servicios.

Como se ilustra en la figura 4, el mapa 50 ilustra una serie de iconos representativos de vehículos (de la A a la K) que se mueven en tiempo real. Hay tres zonas de red o áreas 51 también superpuestas en el mapa 50. En una zona de comunicación o área 51, está el vehículo D. En otra zona de comunicación o área 51, están los vehículos A, B, C, E, y H. En otra zona de comunicación o área 51 están los vehículos I, J, y K. Y finalmente, los vehículos F y G no están asociados con una zona de comunicación o área 51.

Si un dispositivo móvil asociado con el vehículo D dejara de comunicarse, puede ser un fallo de comunicación con el dispositivo móvil asociado con el vehículo D o puede ser un fallo en la red de comunicación. Si los dispositivos móviles asociados a los vehículos A, B, C, E y H cesan la comunicación, el fallo más probable es con respecto a la zona de red de comunicación o área asociada con estos vehículos. Análogamente, si los dispositivos móviles asociados con los vehículos I, J, y K debían cesar la comunicación, el fallo más probable es con respecto a la zona de red de comunicación o área asociada con estos vehículos. Sin embargo, si los dispositivos móviles asociados con los vehículos F y G debían interrumpir la comunicación, esto es de esperar, ya que los vehículos ya no están asociados dentro de una zona o área de comunicación.

Refiriéndonos ahora a la figura 14a, a continuación se describe una representación de estado para determinar un fallo de comunicación basado en la comunicación esperada y la comunicación real. Hay dos estados primarios, el estado de determinación de fallos de comunicación del dispositivo remoto y el estado de modo de comunicación esperado del dispositivo móvil. El estado de modo de comunicación esperado del dispositivo móvil incluye un subestado de modo activo y un subestado de modo inactivo. El estado de modo inactivo, el representante de los modos de ahorro de energía en niveles para el dispositivo móvil incluye además dos subestados, un estado de suspensión y un estado de suspensión profunda.

El estado de determinación de fallos de comunicación del dispositivo remoto y el estado del modo de comunicación esperado del dispositivo móvil son asíncronos y pueden ser concurrentes o no concurrentes. El estado de determinación de fallos de comunicación del dispositivo remoto proporciona una determinación de un fallo de comunicación potencial al comparar el número total de comunicaciones esperadas de una pluralidad de dispositivos móviles con el número real de comunicaciones en una muestra de marco de tiempo particular.

El modo activo se produce cuando un dispositivo móvil está completamente encendido y operativo. El modo activo proporciona una primera frecuencia periódica de comunicación, o una primera comunicación esperada para el dispositivo remoto. En una realización de la invención, la primera frecuencia de comunicación es cada 100 segundos y los expertos en la técnica apreciarán que la primera frecuencia de comunicación puede incluir otros valores diferentes.

El modo inactivo se produce cuando un dispositivo móvil se apaga al menos en un modo de ahorro de energía. El subestado o modo de suspensión es un primer modo de ahorro de energía y proporciona una segunda frecuencia periódica de comunicación, o una segunda comunicación esperada para el dispositivo remoto. En una realización de la invención, la segunda frecuencia de comunicación es cada 30 minutos, o 1800 segundos, y los expertos en la técnica también apreciarán que la segunda frecuencia de comunicación puede incluir otros valores diferentes. El subestado o modo de suspensión profunda es un segundo modo de ahorro de energía y proporciona una tercera frecuencia periódica de comunicación, o una tercera comunicación esperada para el dispositivo remoto. En una realización de la invención, la segunda frecuencia de comunicación es cada 24 horas, u 86.400 segundos, y los expertos en la técnica también apreciarán que la tercera frecuencia de comunicación puede incluir otros valores diferentes.

Las tres frecuencias de comunicación proporcionan tres marcos de tiempo de comunicación esperados conocidos, o umbrales para el dispositivo remoto. La comunicación esperada podría ser en forma de una señal, datos, y/o un mensaje que depende del dispositivo móvil. Por ejemplo, si el dispositivo móvil está listo para comunicar un registro de datos, la comunicación podría ser en forma de datos. Si el dispositivo móvil no está listo para comunicar un registro de datos, la comunicación podría ser en forma de un mensaje con un ID de dispositivo.

La lógica de determinación de fallos de comunicación del dispositivo remoto rastrea y suma las conexiones esperadas basadas en los estados de modo de comunicación esperados del dispositivo móvil y, como se ilustra en la Tabla 2, puede incluir una pluralidad de dispositivos móviles que operan con la primera frecuencia de comunicación, o una pluralidad de dispositivos móviles que operan con la segunda frecuencia de comunicación, o una pluralidad de dispositivos móviles que operan con la tercera frecuencia de comunicación, así como combinaciones de la primera, segunda y tercera frecuencias de comunicación.

T l 2: E m l m ni i n r r n ri i iiv m vil .

Refiriéndonos ahora a la figura 14b, se describe el preprocesamiento de datos para determinar un fallo de comunicación basado en la comunicación esperada y un período de comunicación real. Diferentes tipos y categorías de datos se preprocesan en tiempo real para crear la gran cantidad de datos analíticos telemáticos (ATbD) utilizados para determinar un fallo de comunicación de red. El preprocesamiento puede ser con un servidor de propósito especial 19, u otro dispositivo informático 20. El registro de datos del dispositivo GO (RTbD) es un dato histórico durante un período de tiempo e incluye al menos un dato de GPS y una indicación del estado del vehículo. Los datos complementarios (SD) incluyen datos de ubicación y datos de red. El registro de datos del dispositivo GO (RTbD) se combina con los datos complementarios (SD) para formar los datos analíticos (ATbD). Los datos complementarios se pueden obtener internamente con el sistema o externamente al sistema. En una realización de la invención, los datos de GPS son en forma de coordenadas de latitud y longitud, incluyendo una indicación de tiempo, y los datos de estado del vehículo son una indicación de encendido o apagado del motor u otra indicación representativa de un modo activo y un modo inactivo para el dispositivo móvil. En una realización de la invención, los datos de ubicación pueden incluir al menos uno de un código postal, un código postal, una dirección, una indicación de la carretera, una indicación de la autopista, un nombre, información de contacto o un número de teléfono. En una realización de la invención, los datos de la red pueden incluir al menos uno de un nombre de proveedor de servicios, un área de red, una zona de red o una indicación de célula de red.

El preprocesamiento de datos puede incluir una capacidad de escala automática para equilibrar la transmisión en tiempo real de los datos. En algunas realizaciones de la invención, la capacidad de escala automática puede ser una memoria intermedia, una memoria intermedia doble o una combinación de una memoria intermedia y una memoria intermedia doble.

Refiriéndonos ahora a la figura 15, se describe la lógica de determinación del período de comunicación esperado del dispositivo móvil. El dispositivo móvil detecta el estado del vehículo. En una realización de la invención, la detección se produce entre la interfaz 36 del sistema de hardware de telemetría del vehículo 30 y el bus de comunicaciones de la red del vehículo 37. Una vez detectado el estado del vehículo, el estado del vehículo se verifica para determinar si el estado es verdadero o falso. En una realización de la invención, el estado del vehículo es un código para "encendido" y si el estado es "on", la verificación es verdadera o si el estado es "off', la comprobación es falsa. Si la comprobación es verdadera, entonces el modo activo se configura para indicar un primer período de comunicación. Si la comprobación es falsa, entonces se establece el modo inactivo. Para el caso en el que hay una pluralidad de modos de ahorro de energía, se realiza una verificación posterior con respecto a un umbral de período inactivo. Si no se ha alcanzado el umbral (indicativo de un primer modo de ahorro de energía), entonces se establece un segundo período de comunicación. Si se ha alcanzado el umbral (indicativo de un segundo modo de ahorro de energía), entonces se establece un tercer período de comunicación.

Una vez que el primer o el segundo o el tercer período de comunicación se ha establecido o restablecido entre los períodos basados en la lógica, el dispositivo móvil se comunica con un dispositivo remoto basado en uno de los periodos de comunicación como una comunicación esperada. El estado del vehículo se verifica para determinar si el estado del vehículo ha cambiado. Entonces, la lógica de determinación del período de comunicación esperado del dispositivo móvil se ejecuta en cada dispositivo móvil. En una realización de la invención, la lógica de determinación del período de comunicación esperado del dispositivo móvil también es un primer proceso asíncrono.

Refiriéndonos ahora a la figura 16a, la lógica de determinación activa/inactiva del dispositivo remoto para cada dispositivo móvil se describe a continuación. El dispositivo remoto establece un marco de tiempo o tiempo de muestra para verificar y determinar la presencia de uno o más fallos de comunicación. Entonces, el dispositivo remoto recibe registros de datos de dispositivos móviles de cada uno de los dispositivos remotos dentro del marco de tiempo de la muestra. Para cada dispositivo de registro de datos, el registro anterior se decodifica para identificar el indicador de estado del vehículo a partir del registro. Si el estado del vehículo es verdadero, entonces el dispositivo remoto determina que el dispositivo móvil está en modo activo. Si el estado del vehículo es falso, entonces el dispositivo remoto determina que el dispositivo móvil está en modo inactivo. El dispositivo remoto puede entonces rastrear cada dispositivo móvil y el estado correspondiente de activo o inactivo.

Refiriéndonos ahora a la figura 16b, se describe la lógica de determinación de comunicación esperada del dispositivo remoto para cada dispositivo móvil. El dispositivo remoto recibe una pluralidad de registros de datos de dispositivos móviles dentro de la muestra de marco de tiempo de comunicación. Para cada registro de datos, se determina el estado del vehículo. Si el estado del vehículo es verdadero, entonces el dispositivo móvil está en modo activo con una comunicación esperada de un primer período de frecuencia. Si el estado del vehículo es falso, entonces se comprueba el umbral del período inactivo. Si no se ha alcanzado el umbral, entonces el dispositivo móvil está en modo inactivo con una comunicación esperada de un segundo período de frecuencia. Si se ha alcanzado el umbral, entonces el dispositivo móvil está en modo inactivo con una comunicación esperada de un tercer período de frecuencia. El dispositivo remoto rastrea cada modo de dispositivo móvil, la comunicación esperada y el período de frecuencia para el uso y la comparación con la recepción del siguiente conjunto de registros de dispositivos móviles en la siguiente muestra de marco de tiempo de comunicación para la comparación con el siguiente número de comunicaciones reales desde los dispositivos móviles.

En una realización de la invención, la lógica de determinación activa/inactiva del dispositivo remoto para cada dispositivo móvil y la lógica de determinación del período de comunicación esperado del dispositivo remoto también son un segundo proceso simultáneo asíncrono.

Refiriéndonos ahora a la figura 16c, se describe la lógica de determinación de fallos de comunicación esperada y real del dispositivo remoto. Cuando se ha alcanzado el período de muestra de marco de tiempo de comunicación, se determina el número total de conexiones esperadas. El número total de conexiones esperadas es la suma del número de dispositivos móviles en un modo activo con una conexión esperada de un primer período de frecuencia más la cantidad de dispositivos móviles en un modo inactivo con una conexión esperada de un segundo período de frecuencia. Alternativamente, el número total de conexiones esperadas también puede incluir el número de dispositivos en un modo inactivo con una conexión esperada de un tercer período de frecuencia.

Se realiza una comparación con respecto al número total de conexiones reales con el número de dispositivos móviles que realmente se conectaron. Cuando el número total de conexiones esperadas es igual al número total de conexiones reales, no hay ningún fallo en las comunicaciones. Cuando el número total de conexiones esperadas no es igual al número total de conexiones reales, hay un fallo en las comunicaciones. Cuando hay un fallo en las comunicaciones, para cada dispositivo móvil que no se conectó, se accede a las coordenadas GPS aumentadas a partir de los datos y compárelas con una zona de red o área o célula para determinar la ubicación del fallo en la red. Refiriéndonos ahora a la figura 17, se describe la lógica de determinación de fallos de comunicación de la red del dispositivo remoto. Para cada determinación de fallo de comunicación asociado con un dispositivo móvil, se determinan las coordenadas GPS aumentadas a partir de los datos para el dispositivo móvil que se esperaba que se comunicaran y no se comunicaron. Se determina el área de la red, la zona o la célula según las coordenadas GPS aumentadas de los datos. Alternativamente, se determina el área de la red, la zona o la célula según las coordenadas GPS del registro de datos y los datos complementarios o los datos aumentados. Se correlaciona la ubicación del dispositivo móvil según las coordenadas GPS con el área de la red, la zona o la célula según las coordenadas GPS del dispositivo móvil o, alternativamente, las coordenadas GPS y los datos adicionales o los datos aumentados. Se proporciona una indicación de fallo en relación con cada dispositivo móvil que no se comunicó y el área o zona o célula de la red. Se repite para cada dispositivo móvil que no se comunicó cuando se espera que se comunique.

La indicación de fallo puede ser en forma de una indicación gráfica en el mapa 50 que identifica el(los) dispositivo(s) móvil(es) y el área o zona o célula de la red asociada. Alternativamente, la indicación de fallo puede ser un mensaje de texto o un mensaje de audio que indica el fallo y el área o zona o célula asociada a la red o el informe.

Sumario

En resumen, el sistema de identificación de fallos de comunicación de la red de grandes cantidades de datos de telemáticas incluye una serie de componentes informáticos especializados basados en hardware, firmware, software, dispositivos móviles, dispositivos remotos, tecnología telemática y tecnología de telecomunicaciones. Realizaciones de la presente invención, incluyendo los dispositivos, sistema y métodos, proporcionan individualmente y/o colectivamente uno o más efectos técnicos. Capacidad para proporcionar una visión y un análisis más profundos del negocio en tiempo real en función de la disponibilidad más rápida de las grandes cantidades de datos analíticos telemáticos en tiempo real. Mejora del tiempo de respuesta de la determinación de fallos en la comunicación de red basada en el acceso en tiempo real a grandes cantidades de datos de telemáticas en tiempo real (ATbD). Acceso más rápido a grandes cantidades de datos de telemáticas analíticas (ATbD) y un ciclo más corto para la información de fallos de comunicación de red. Acceso a un conjunto diverso de múltiples petabytes de datos en una única fuente de datos en la nube para admitir el análisis de determinación de fallos en las comunicaciones de red. Grandes cantidades de datos de telemáticas en tiempo real que pueden incorporar datos de traducción y datos alterados en la transformación a grandes cantidades de datos de telemáticas analíticas (ATbD). Grandes cantidades de datos de telemáticas en tiempo real que pueden incorporar datos de aumento y datos alterados en la transformación a grandes cantidades de datos de telemáticas analíticas (ATbD). En una realización de ejemplo de la invención, identificación de problemas de determinación de fallos de comunicación de red impredecibles. Un dispositivo, sistema y métodos capaces de preprocesar registros de grandes cantidades de datos de telemáticas sin procesar (RTbD) en tiempo real de acuerdo con las necesidades y los requisitos específicos para los tipos de datos específicos contenidos en los registros.

Si bien la presente invención se ha descrito con respecto a las realizaciones no limitativas, debe entenderse que la invención no está limitada a las realizaciones descritas. Las personas expertas en la técnica entienden que la invención descrita está destinada a cubrir diversas modificaciones y disposiciones equivalentes incluidas dentro del alcance de las reivindicaciones adjuntas. Por lo tanto, la presente invención no debe estar limitada por ninguna de las realizaciones descritas.

Claims

REIVINDICACIONES

1. Un sistema de determinación de fallos de comunicación de grandes cantidades de datos de telemáticas, que comprende:

al menos un dispositivo móvil (30) y al menos un dispositivo remoto (19, 20),

pudiendo dicho al menos un dispositivo móvil (30) que sea capaz de comunicar al menos uno de una señal o datos o un mensaje a dicho al menos dispositivo remoto (19, 20),

estando dicho al menos un dispositivo móvil (30) configurado para asumir un estado de modo de comunicación esperado del dispositivo móvil para proporcionar marcos de tiempo de comunicación esperados para dicho al menos un dispositivo remoto (19, 20),

incluyendo dicho estado de modo de comunicación esperado un subestado de modo activo y un subestado de modo inactivo, en el que dicho subestado de modo activo proporciona una primera comunicación periódica con un primer período de comunicación para el dispositivo remoto cuando dicho al menos un dispositivo móvil (30) está completamente encendido, y

en el que dicho subestado de modo inactivo proporciona una segunda comunicación periódica con un segundo período de comunicación para dicho al menos un dispositivo remoto (19, 20) cuando dicho al menos un dispositivo móvil (30) se apaga en un primer modo de ahorro de energía, y una tercera comunicación periódica con un tercer período de comunicación para dicho al menos un dispositivo remoto (19, 20) cuando dicho al menos un dispositivo móvil (30) se apaga en un segundo modo de ahorro de energía;

estando dicho al menos un dispositivo remoto (19, 20) configurado para asumir un estado de determinación de fallo de comunicación para monitorizar el período de comunicación esperado y el período de comunicación real de cada uno de dicho al menos un dispositivo móvil (30), y para determinar un fallo cuando dicho período de comunicación real es diferente de dicho período de comunicación esperado.

2. Un sistema de determinación de fallos de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 1, en el que dicho primer período de comunicación es un período de 100 segundos.

3. Un sistema de determinación de fallos de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 1, en el que dicho segundo período de comunicación es un período de 1800 segundos.

4. Un sistema de determinación de fallos de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 1, en el que dicho tercer período de comunicación es un período de 86.400 segundos.

5. Un sistema de determinación de fallos de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 1, en el que dicho al menos un dispositivo móvil (30) incluye además un dispositivo posicional,

dicho dispositivo posicional para incluir una indicación de posición de dicho al menos un dispositivo móvil (30) con dicha comunicación al menos uno de una señal o datos o mensaje,

en el que dicho dispositivo remoto (19, 20) está configurado para determinar una ubicación de un fallo de comunicación mediante una última indicación de posición conocida de dicho dispositivo móvil.