ES2675848T3

ES2675848T3 - Método de sistema de identificación de fallo de comunicación de red de grandes cantidades de datos de telemáticas

Info

Publication number: ES2675848T3
Application number: ES17204584T
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-06-01
Anticipated expiration: 2037-11-30
Also published as: ES2675848T1; DE17204584T1; EP3331260A1; PL3331260T3; EP3331260B1

Abstract

Un método de sistema de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas que comprende: al menos un primer proceso concurrente para cada uno de al menos un dispositivo móvil, y al menos un segundo proceso concurrente para al menos un dispositivo remoto, determinando dicho primer proceso concurrente un modo activo o un modo inactivo y estableciendo un periodo de comunicación para comunicar con dicho al menos un dispositivo remoto, pudiendo dicho al menos un dispositivo remoto comunicar al menos uno de una señal, o datos o mensaje a dicho al menos un dispositivo remoto en dicho periodo de comunicación, pudiendo dicho al menos un segundo proceso concurrente recibir dicha al menos una señal, o datos, o mensaje y determinar un modo activo o un modo inactivo y correspondiente periodo de comunicación para cada uno de dicho al menos un dispositivo móvil, en el que en un marco temporal de determinación de fallo de comunicación dicho al menos un segundo proceso concurrente determina el número de dicho al menos un dispositivo móvil esperado para comunicar con el número de dicha al menos una comunicación real de dispositivo móvil para indicar la presencia de un fallo de comunicación cuando el número esperado es diferente del número real para cada uno de dicho al menos un dispositivo móvil que comunicó.

Description

DESCRIPCIÓN

Método de sistema de identificación de fallo 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 continuación parcial de solicitud de patente de la solicitud de patente de Estados Unidos con 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 de grandes cantidades de datos, método y sistema para aplicación en entornos de telemetría vehicular. Más específicamente, la presente invención se refiere a un sistema de identificación de fallo de comunicación de red de grandes cantidades de datos de telemáticas en tiempo real de dispositivo móvil.

Antecedentes de la invención

Sistemas de telemetría vehicular se conocen en la técnica anterior en la que un vehículo puede estar equipado con un dispositivo de hardware de telemetría vehicular para supervisar y registrar un intervalo de parámetros de vehículo. Un ejemplo de un dispositivo de este tipo es un dispositivo de Geotab™ GO. El dispositivo de Geotab GO interactúa con el vehículo a través de un puerto de diagnóstico a bordo (OBD) para ganar acceso a la red de vehículo y unidad de control de motor. Una vez interconectado y operacional, el dispositivo de Geotab GO supervisa el bus de vehículo y crea un registro de datos de vehículos sin procesar. El dispositivo de Geotab GO puede mejorarse adicionalmente a través de un expansor de E/S de Geotab para acceder y supervisar otras variables, sensores y dispositivos resultando en un registro de datos sin procesar más grande y más complejo. Adicionalmente, el dispositivo de Geotab GO puede incluir adicionalmente una capacidad de GPS para rastrear y registrar datos de GPS sin procesar. El dispositivo de Geotab GO también puede incluir un acelerómetro para supervisar y registrar datos de acelerómetro sin procesar. La operación en tiempo real de una pluralidad de dispositivo de Geotab GO crea y comunica múltiples registros complejos de algunos o todos estos datos sin procesar combinados a un sitio remoto para posterior análisis.

Los datos se consideran que son grandes cantidades de datos de telemáticas 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 comunica un sitio remoto a su debido tiempo. Por ejemplo, el 10 de diciembre de 2014 había aproximadamente 250.000 dispositivos de Geotab GO en operación activa supervisando, rastreando y comunicando múltiples registros complejos de grandes cantidades de datos de telemáticas sin procesar a un centro de datos de Geotab. El volumen de grandes cantidades de datos de telemáticas sin procesar en un único día excede los 300 millones de registros y más de 40 GB de grandes cantidades de datos de telemáticas sin procesar.

El anterior enfoque para transformar las grandes cantidades de datos de telemáticas sin procesar en un formato para uso con una base de datos SQL y correspondiente proceso de analítica era retardar y copiar cada día completo de grandes cantidades de datos de telemáticas sin procesar a una base de datos separada en la que las grandes cantidades de datos de telemáticas sin procesar podrían procesarse y decodificarse en un formato que podría proporcionar valor significativo en un proceso de analítica. Este anterior enfoque consume muchos recursos y se ejecuta habitualmente por la noche cuando el número de dispositivos activos de Geotab GO es mínimo. En este ejemplo, el procesamiento y decodificación de las grandes cantidades de datos de telemáticas sin procesar requirieron más de 12 horas para cada día de grandes cantidades de datos de telemáticas sin procesar. El proceso de analítica y correspondiente información útil para gestores de flotas que realizan actividades de gestión de flotas tiene una antigüedad de al menos 1,5 días, influenciando negativamente en cualquier decisión de gestión de flotas sensible al tiempo real.

Anteriores enfoques para supervisar grandes cantidades de datos de telemáticas de tiempo para comunicación de fallos de red se limitaron anteriormente debido al procesamiento y retardos en la recepción de datos. Estos retardos de datos y una falta de datos ampliados o complementarios también perjudicaron la capacidad de determinar la localización de un fallo de comunicación de red basándose en coordenadas de dispositivo móvil en tiempo real.

El documento US2001041566 A1 proporciona para un método y sistema para medir datos calidad de servicio en una red inalámbrica usando múltiples instrumentos itinerantes (es decir, móviles) y/o estacionarios, no atendidos, de posición y de rendimiento (PUPPI) que se controlan remotamente por un procesador de extremo final. El sistema incluye un elemento que se ubica dentro de la infraestructura de red inalámbrica, por ejemplo, en la pasarela WAP para supervisar el protocolo de datos inalámbrico y para realizar mediciones de análisis comparativo.

Sumario de la invención

La presente invención se refiere a aspectos en un entorno de telemetría vehicular. La presente invención proporciona una nueva capacidad para un sistema de identificación de fallo de comunicación de red de grandes cantidades de datos de telemáticas en tiempo real de dispositivo móvil. Realizaciones de la invención se efectúan de acuerdo con las reivindicaciones independientes adjuntas.

De acuerdo con un aspecto amplio de la invención, existe un método de identificación de fallo de comunicación de red de telemáticas. El método incluye al menos un primer proceso concurrente para cada uno de al menos un dispositivo móvil y al menos un segundo proceso concurrente para el al menos un dispositivo remoto. Determinando el primer proceso concurrente un modo activo o un modo inactivo y estableciendo un periodo de comunicación para comunicar con el al menos un dispositivo remoto.

El al menos un dispositivo remoto capaz de comunicar al menos uno de una señal, o datos, o mensaje al al menos un dispositivo remoto dentro del periodo de comunicación. El al menos un segundo proceso concurrente capaz de recibir la al menos una señal, o datos, o mensaje y determinar un modo activo o un modo inactivo y correspondiente periodo de comunicación para cada uno del al menos un dispositivo móvil. Dentro de un marco temporal de determinación de fallo de comunicación el al menos un segundo proceso concurrente determina el número del al menos un dispositivo móvil esperado para comunicación con el número de la al menos una comunicación real de dispositivo móvil para indicar la presencia de un fallo de comunicación con el número esperado es diferente del número real para cada del al menos un dispositivo móvil que comunicó.

El estado de modo de comunicación esperada puede incluir un estado de modo activo y un estado de modo inactivo. El estado de modo inactivo puede incluir adicionalmente un estado de inactividad. El estado de modo inactivo puede incluir adicionalmente un estado de inactividad profunda. El estado de modo activo puede incluir adicionalmente un primer periodo de comunicación oportuna para comunicar con el dispositivo remoto. El estado de inactividad puede incluir adicionalmente un segundo periodo de comunicación oportuna para comunicar con el dispositivo remoto. El estado de inactividad profunda puede incluir adicionalmente un tercer periodo de comunicación oportuna para comunicación el dispositivo remoto. El primer periodo de comunicación oportuna puede establecer adicionalmente una primera comunicación esperada. El segundo periodo de comunicación oportuna puede establecer adicionalmente una segunda comunicación esperada. El tercer periodo de comunicación oportuna puede establecer adicionalmente 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 periodo de 1800 segundos. En una realización de la invención, la tercera comunicación esperada es un periodo de 86.400 segundos. El estado de modo de comunicación esperada puede incluir adicionalmente una pluralidad de periodos de comunicación oportuna. La pluralidad de periodos de comunicación oportuna pueden ser adicionalmente diferentes intervalos de tiempo. Los diferentes intervalos de tiempo pueden incluir adicionalmente 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 periodo de 100 segundos. En otra realización de la invención, la al menos una frecuencia de comunicación incluye un periodo de 1800 segundos. En otra realización de la invención, la al menos una frecuencia de comunicación incluye un periodo de 86.400 segundos.

El dispositivo móvil puede incluir adicionalmente un dispositivo posicional, el dispositivo posicional para incluir 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 una localizació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 adicionalmente el al menos un primer proceso concurrente que determina un modo activo o un modo inactivo detectando un estado de vehículo. La detección de un estado de vehículo puede basarse adicionalmente en un estado de encendido de un vehículo. El estado de vehículo puede proporcionar adicionalmente una indicación para establecer un modo activo. El modo activo puede incluir adicionalmente un primer periodo de comunicación oportuna para comunicar con el al menos un dispositivo remoto. El estado de vehículo puede proporcionar adicionalmente una indicación para establecer un modo inactivo. El modo inactivo puede incluir adicionalmente un segundo periodo de comunicación oportuna para comunicar con el al menos un dispositivo remoto. El modo inactivo puede incluir adicionalmente un tercer periodo de comunicación oportuna para comunicación con el al menos un dispositivo remoto. El modo inactivo puede incluir adicionalmente 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 adicionalmente en un tiempo de 86.400 segundos y tras exceder el tiempo de 86.400 segundos, iniciar la transición de la segunda comunicación esperada a la tercera comunicación esperada. El segundo proceso concurrente puede determinar adicionalmente o bien un modo activo o bien un modo inactivo para cada uno del 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. Un estado de encendido de un vehículo puede contenerse adicionalmente en la señal, o datos, o mensaje para determinar un modo activo o un modo inactivo. El modo activo puede incluir adicionalmente un primer periodo de comunicación oportuna para comunicar con el dispositivo remoto. El modo inactivo puede incluir adicionalmente un segundo periodo de comunicación oportuna para comunicación con el al menos un dispositivo remoto. El modo inactivo puede incluir adicionalmente un tercer periodo de comunicación oportuna para comunicación con el al menos un dispositivo remoto.

El al menos un periodo de comunicación esperada puede basarse adicionalmente en un modo activo. El modo activo puede incluir adicionalmente un primer periodo de comunicación oportuna para comunicar con el dispositivo remoto.

El al menos un periodo de comunicación esperada puede basarse adicionalmente en un modo inactivo. El modo inactivo puede incluir adicionalmente un segundo periodo de comunicación oportuna para comunicar con el dispositivo remoto. El modo inactivo puede incluir adicionalmente un tercer periodo de comunicación oportuna para comunicar 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 de DTE 31, un microprocesador de comunicaciones 32 y memoria. El microprocesador de comunicaciones 32 puede habilitarse para comunicaciones celulares, comunicación por satélites u otra forma de comunicaciones para comunicación con un dispositivo remoto. El sistema de hardware de telemetría 30 también puede incluir un expansor de E/S 50. Un dispositivo posicional puede ser integral al sistema de hardware de telemetría 30, tal como el módulo de GPS 33 o el dispositivo posicional puede ser accesible a través de la interfaz de mensajería 53 o un expansor de E/S 50. El sistema de hardware de telemetría 30 también puede incluir un acelerómetro 34. Un ejemplo dispositivo móvil es un dispositivo de Geotab™ GO.

En una realización de la invención, el dispositivo remoto es al menos un servidor de fin 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 sobremesa, ordenadores de dispositivos de mano, ordenadores de teléfonos inteligentes, ordenadores de tableta, ordenadores portátiles, dispositivos llevables 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 informática en la nube. Un ejemplo de software de aplicación es la aplicación de gestión de flota de 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. Expertos en la materia que se contemplan otras formas de comunicación mediante 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 de vehículo se basa en datos e información de vehículo. Un estado de vehículo de ejemplo es el estado de encendido de o bien "CONECTADO" o bien "DESCONECTADO". El estado de vehículo también puede seleccionarse a partir de uno o más otros indicadores de estado de vehículo de los datos e información de vehículo.

Estos y otros aspectos y características de realizaciones no limitantes son evidentes a los expertos en la materia tras la revisión de la siguiente descripción detallada de las realizaciones no limitantes y los dibujos adjuntos.

Breve descripción de los dibujos

Realizaciones no limitantes ilustrativas 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 nivel alto de una infraestructura y entorno 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 comunica con al menos un expansor de E/S inteligente;

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

La Figura 2d es una vista esquemática de al menos un expansor de E/S inteligente con un módulo de Bluetooth integral con capacidad de comunicación con al menos un módulo de baliza;

La Figura 2e es una vista esquemática de un expansor de E/S inteligente y dispositivo con capacidad de comunicación 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 flujo de grandes cantidades de datos de telemáticas sin procesar entre los dispositivos móviles y servidores;

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

La Figura 6a es una representación esquemática de una realización del constructor de grandes cantidades de datos de telemáticas analíticas;

La Figura 6b es una representación esquemática de una realización del constructor de grandes cantidades de datos de telemáticas analíticas que ilustra una pluralidad de tipos de datos a preservar;

La Figura 6c es una representación esquemática de otra realización del constructor de grandes cantidades de datos de telemáticas analíticas que ilustra adicionalmente una pluralidad de tipos de modificación de datos de datos modificados;

La Figura 7a es una representación esquemática de otra realización del constructor de grandes cantidades de datos de telemáticas analíticas que ilustra adicionalmente una primera memoria intermedia para acomodar el modificador de datos y 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 de grandes cantidades de datos de telemáticas analíticas que ilustra adicionalmente una segunda memoria intermedia para acomodar un retardo o errores en el flujo de datos a través del constructor de grandes cantidades de datos de telemáticas analíticas;

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

La Figura 8a es una representación esquemática de otra realización del constructor de grandes cantidades de datos de telemáticas analíticas que ilustra adicionalmente un par de servidores de información complementaria para datos de traducción y datos de ampliación;

La Figura 8b es una representación esquemática de otra realización del constructor de grandes cantidades de datos de telemáticas analíticas que ilustra adicionalmente un servidor de información complementaria para datos de traducción;

La Figura 8c es una representación esquemática de otra realización del constructor de grandes cantidades de datos de telemáticas analíticas que ilustra adicionalmente un servidor de información complementaria para datos de ampliación;

La Figura 9a es una representación esquemática de otra realización del constructor de grandes cantidades de datos de telemáticas analíticas que ilustra adicionalmente una primera memoria intermedia para acomodar el modificador de datos y un par de servidores de información complementaria para datos de traducción y datos de ampliación;

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

La Figura 9c es una representación esquemática de otra realización del constructor de grandes cantidades de datos de telemáticas analíticas que ilustra adicionalmente una primera memoria intermedia para acomodar el modificador de datos y un servidor de información complementaria para datos de ampliación;

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

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

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

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 ampliación y grandes cantidades de datos de telemáticas analíticas;

La Figura 12a es una representación esquemática de 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 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 adicionalmente un número de subestados de modificador de datos;

La Figura 12c es una representación esquemática de 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 adicionalmente un par de ejemplo de subestados de modificador de datos para datos a traducir y datos a ampliar;

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

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

La Figura 13c es una representación esquemática de la lógica y tareas de estado de modificador de datos; La Figura 13d es una representación esquemática de la lógica y tareas de estado de amalgamador de datos para procesamiento secuencial; La Figura 13e es una representación esquemática de la lógica y tareas de estado de amalgamador de datos para procesamiento en paralelo; La Figura 13f es una representación esquemática de la lógica y tareas de estado transferencia de datos;

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

La Figura 14b, es una representación esquemática de procesamiento de datos para determinar un fallo de comunicación de red basándose en comunicación esperada y un periodo de comunicación real;

La Figura 15 es una representación esquemática de periodo de lógica de determinación de comunicación esperada

para un dispositivo móvil;

La Figura 16a es una representación esquemática de la lógica de 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 de 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 de dispositivo remoto para determinar un fallo basándose 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 fallo de comunicación de red de dispositivo remoto.

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

Descripción detallada

Infraestructura y entorno de telemetría vehicular

Haciendo referencia a la Figura 1 de los dibujos, se ilustra una visión de conjunto de nivel alto de una infraestructura y entorno de telemetría vehicular. Hay al menos un vehículo indicado generalmente 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 de E/S inteligente 50 (no mostrado). Además, puede haber al menos un módulo de Bluetooth 45 (no mostrado) para comunicación con al menos uno del sistema de hardware de telemetría vehicular 30 o el expansor de E/S inteligente 50.

El sistema de hardware de telemetría vehicular 30 supervisa y registra una primera categoría de datos de telemáticas sin procesar conocidos como datos de vehículo.

El sistema de hardware de telemetría vehicular 30 también puede supervisar 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 supervisar y registrar una tercera categoría de datos de telemáticas sin procesar conocidos como datos de acelerómetro.

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

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

Expertos en la materia aprecian que las cinco categorías de datos son ilustrativas y pueden incluir adicionalmente 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, datos de coordenadas de GPS es un grupo o tipo de datos similares. Datos de acelerómetro es 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. Expertos en la materia también aprecian que la composición, formato y 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 es también significativamente diferente y la frecuencia y temporización para comunicar los datos pueden variar enormemente. Expertos en la materia aprecian adicionalmente que la supervisión, registro y la comunicación de múltiples registros o datos de telemáticas sin procesar resulta en la creación de grandes cantidades de datos de telemáticas sin procesar.

La infraestructura y entorno de telemetría vehicular también proporciona comunicación e intercambio de datos de telemáticas sin procesar, información, órdenes y mensajes entre el al menos un servidor de fin especial 19, al menos un dispositivo informático 20 (ordenadores de sobremesa, ordenadores de dispositivos de mano, ordenadores de teléfonos inteligentes, ordenadores de tableta, ordenadores portátiles, dispositivos llevables y otros dispositivos informáticos) y los vehículos 11. En un ejemplo, la comunicación 12 es a/desde un satélite 13. El satélite 13 a su vez comunica con un sistema terrestre 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. Ejemplos adicionales de dispositivos de comunicación incluyen dispositivos Wi-Fi y dispositivos Bluetooth conectados a la red informática 18.

El dispositivo informático 20 y servidor de fin especial 19 con correspondiente software de aplicación se comunican a través de la red informática 18. En una realización de la invención, el software de aplicación de gestión de flota de MyGeotab™ se ejecuta en un servidor de fin especial 19. El software de aplicación también puede basarse en informática en la nube. Clientes que operan un dispositivo informático 20 se comunican con el software de aplicación de gestión de flota de MyGeotab que se ejecuta en el servidor de fin especial 19. Pueden enviarse y recibirse datos, información, mensajes y comandos a través de la infraestructura y entorno de comunicación entre el sistema de hardware de telemetría vehicular 30 y el servidor de fin especial 19.

Pueden enviarse datos e información desde el sistema de hardware de telemetría vehicular 30 a la red celular 17, a la red informática 18 y al al menos un servidor de fin especial 19. Dispositivos informáticos 20 pueden acceder a los datos e información en los servidores de fin especial 19. Como alternativa, pueden enviarse datos, información y comandos desde el al menos un servidor de fin especial 19, a la red 18, a la red celular 17 y al sistema de hardware de telemetría vehicular 30.

También pueden enviarse datos e información desde sistema de hardware de telemetría vehicular a un expansor de E/S inteligente 50, a un dispositivo de Iridium™, al satélite 13, a la estación terrestre 15, a la red informática 18 y al al menos un servidor de fin especial 19. Dispositivos informáticos 20 pueden acceder a datos e información en los servidores de fin especial 19. También puede enviarse datos, información y comandos desde el al menos un servidor de fin especial 19, a la red informática 18, a la estación terrestre 15, al satélite 13, a un dispositivo de Iridium, a un expansor de E/S inteligente 50 y a un sistema de hardware de telemetría vehicular.

Sistema de hardware de telemetría vehicular

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

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

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

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

El microprocesador de telemetría de DTE 31 tiene la capacidad, a través de la interfaz de OBD 36 cuando se conecta al bus de comunicaciones de red de vehículo 37, de supervisar y recibir datos e información de vehículo desde los componentes de sistema vehicular residente para procesamiento adicional.

Como un breve ejemplo no limitante de una primera categoría de datos de telemáticas sin procesar e información de vehículo, la lista puede incluir pero sin limitación: un VIN (número de identificación de vehículo), lectura de odómetro actual, velocidad actual, RPM del motor, tensión de batería, temperatura de refrigerante del motor, nivel de refrigerante del motor, posición del pedal del acelerador, posición del pedal del freno, diversos DTC (códigos de problemas de diagnóstico) de vehículo específicos del fabricante, presión de neumáticos, presión del 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. Se entiende adicionalmente que la cantidad y tipo de datos de vehículos sin procesar e información cambiará 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 de DTE 31, este se interconecta adicionalmente para comunicación con el microprocesador de comunicaciones de telemetría inalámbrico de DCE 32. En una realización de la invención, un ejemplo del microprocesador de comunicaciones de telemetría inalámbrico de DCE 32 es un Leon 100 disponible comercialmente en 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 a/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 fin especial 19 conectados a través de una red informática 18 (véase la Figura 1). Además, la estación terrestre puede incluir software de aplicación informático para adquisición de datos, análisis y enviar/recibir comandos a/desde el sistema de hardware de telemetría vehicular 30.

El microprocesador de telemetría de DTE 31 se interconecta también para comunicación al módulo de GPS 33. En una realización de la invención, un ejemplo del módulo de GPS 33 es un Neo-5 disponible comercialmente en u-blox Corporation. El Neo-5 proporciona capacidad y funcionalidad de receptor GPS al sistema de hardware de telemetría vehicular 30. El módulo de GPS 33 proporciona las coordenadas de latitud y longitud como una segunda categoría de datos de telemáticas sin procesar e información.

El microprocesador de telemetría de DTE 31 se interconecta adicionalmente con una memoria no volátil externa 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 en Atmel Corporation. La memoria 35 de la presente invención se usa para registrar datos sin procesar.

El microprocesador de telemetría de DTE 31 se interconecta adicionalmente para comunicación con un acelerómetro 34. Un acelerómetro (34) es un dispositivo que mide la aceleración física experimentada por un objeto. Hay disponibles modelos de acelerómetros de un solo eje o múltiples ejes para detectar la magnitud y dirección de la aceleración, o fuerza g, y el dispositivo también puede usarse para detectar orientación, aceleración de coordenadas, vibración, choque y caída. 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 en STMicroelectronics. El circuito integrado de LIS302DL es un acelerómetro lineal de tres ejes de baja potencia ultra compacto que incluye un elemento de detección una interfaz de IC capaz de 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 de DTE (31), a través de una interfaz en serie de I2C/SPI (Circuito Inter-Integrado) (Interfaz de Periféricos Serie). El circuito integrado de LIS302DL tiene un intervalo a escala completa seleccionable por el usuario de -2 g y -8 g, umbrales programables, y es capaz de medir aceleraciones con una tasa de datos de salida de 100 Hz o 400 Hz.

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

Haciendo referencia ahora a la Figura 2b de los dibujos, se ilustra un sistema de hardware de telemetría vehicular indicado generalmente en 30 que se comunica adicionalmente con al menos un expansor de 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 se conecta al microprocesador de telemetría de DTE 31. Además, una interfaz de mensajería 53 en un expansor de E/S inteligente 50 puede conectarse por el bus privado 55. El bus privado 55 permite que se envíen y reciban mensajes entre el sistema de hardware de telemetría vehicular 30 y el expansor de E/S inteligente, o una pluralidad de expansores de E/S (no mostrados). El sistema de hardware de expansor de E/S inteligente 50 también incluye un microprocesador 51 y memoria 52. Como alternativa, el sistema de hardware de expansor de E/S inteligente 50 incluye un microcontrolador 51. Un microcontrolador incluye una CPU, RAM, ROM y periféricos. Expertos en la materia aprecian que el término procesador contempla o bien un microprocesador y memoria o bien un microcontrolador en todas las realizaciones del hardware divulgado (sistema de hardware de telemetría de vehículo 30, sistema de hardware de expansor de E/S inteligente 50, módulo de Bluetooth 45 (Figura 2c) y baliza de Bluetooth 21 (Figura 2c)). El microprocesador 51 se conecta también a la interfaz de mensajería 53 y la interfaz de múltiples dispositivos configurable 54. En una realización de la invención, un microcontrolador 51 es un dispositivo de ARM Cortec-M3 de 32 bits LPC1756 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 de analógico a digital de 12 bits y un convertidor de digital a analógico de 10 bits. En una realización alternativa, el sistema de hardware de expansor de E/S inteligente 50 puede incluir hardware de texto a voz y firmware asociado (no ilustrado) para salida de audio de un mensaje a un operador de un vehículo 11.

El microprocesador 51 y memoria 52 cooperan para supervisar al menos un dispositivo 60 (un dispositivo 62 e interfaz 61) que comunica 56 con el expansor de E/S inteligente 50 a través de la interfaz de múltiples dispositivos configurable 54. Pueden proporcionarse datos e información desde el dispositivo 60 a través de la interfaz de mensajería 53 al sistema de hardware de telemetría vehicular 30 en el que los datos e información se retienen en el registro de datos de telemáticas sin procesar. Datos e información desde un dispositivo 60 asociado con un expansor de E/S inteligente proporciona la 4a categoría de datos de expansor sin procesar y pueden incluir, pero sin limitación, datos de tráfico, horas de datos de servicio, comunicación de campo cercano datos tal como identificador de conductor, datos de sensores de vehículo (distancia, tiempo, cantidad de material (sólido, líquido), datos de peso de báscula para camiones, datos de distracción del conductor, datos de trabajadores remotos, luces de advertencia de autobús escolar y puertas abiertas/cerradas.

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

En una realización, el módulo de Bluetooth 45 es integral con el sistema de hardware de telemetría vehicular 30. Datos e información se comunican 130 directamente desde la baliza de Bluetooth 21 al sistema de hardware de telemetría vehicular 30. En una realización alternativa, el módulo de Bluetooth 45 es integral con el expansor de E/S inteligente. Datos e información se comunican 130 directamente al expansor de E/S inteligente 50 y a continuación 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 de Bluetooth 45 incluye una interfaz 148 para comunicación 56 a la interfaz de múltiples dispositivos configurable 54 del expansor de E/S inteligente 50. Datos e información se comunican 130 directamente al módulo de Bluetooth 45, a continuación se comunican 56 al expansor de E/S inteligente y finalmente se comunican 55 al sistema de hardware de telemetría vehicular 30.

Datos e información desde una baliza de Bluetooth 21 proporcionan la 5a categoría de datos de telemáticas sin procesar y pueden incluir datos e información con respecto a un objeto asociado con una baliza de Bluetooth 21. Estos datos e información incluyen, pero sin limitación, datos de aceleración de objeto, datos de temperatura de objeto, datos de nivel de batería, datos de presión de objeto, datos de luminancia de objeto y datos de sensor de objeto definidos por el usuario. Esta 5a categoría de datos puede usarse para indicar daño a un artículo o una condición peligrosa para un artículo.

Entorno analítico de telemetría vehicular

Haciendo referencia ahora a la Figuras 3, 4 y 5, se describe adicionalmente el entorno analítico de telemetría vehicular. El mapa 50 ilustra un número de los vehículos 11 (A a K) operando en tiempo real. Por ejemplo, Geotab tiene en la actualidad aproximadamente 500.000 dispositivos de Geotab GO operando en 70 países comunicando múltiples registros complejos de datos de telemáticas sin procesar al servidor de fin especial 19. Cada uno de los vehículos 11 tiene al menos un sistema de hardware de telemetría vehicular 30 instalado y operacional con el vehículo 11. Como alternativa, algunos o todos los vehículos 11 pueden incluir adicionalmente un expansor de E/S inteligente 50 que comunica con un sistema de hardware de telemetría vehicular 30. El expansor de E/S inteligente 50 puede incluir adicionalmente dispositivos 60 que comunican con el expansor de E/S inteligente 50 y sistema de hardware de telemetría vehicular 30. Como alternativa, un módulo de Bluetooth 45 puede incluirse con uno del sistema de hardware de telemetría vehicular 30, el dispositivo 60 o el expansor de E/S inteligente 50. Cuando se incluye un módulo de Bluetooth 45, a continuación balizas de Bluetooth 21 pueden comunicar adicionalmente datos con el módulo de Bluetooth 45. Colectivamente, estas realizaciones alternativas y diferentes configuraciones de hardware especializado generan en tiempo real las grandes cantidades de datos de telemáticas sin procesar. El sistema de hardware de telemetría vehicular 30 es capaz de comunicar las grandes cantidades de datos de telemáticas sin procesar a través de la red 18 a otros servidores de fin especial 19 y dispositivos informáticos 20. La comunicación de las grandes cantidades de datos de telemáticas sin procesar puede producirse a intervalos predefinidos. La comunicación también puede desencadenarse debido a un evento tal como un accidente. La comunicación puede ser periódica o aperiódica. La comunicación también puede solicitarse adicionalmente mediante un comando enviado desde un servidor de fin 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. A continuación, dependiendo de la configuración específica anteriormente descrita, cada vehículo 11 también puede incluir adicionalmente en un registro, al menos unos datos de telemáticas sin procesar de categoría 2, categoría 3, categoría 4 y categoría 5 a través del sistema de hardware de telemetría vehicular 30.

Un número de servidores de fin especial 19 son también parte del entorno analítico de telemetría vehicular y comunican a través de la red 18. Los servidores de fin especial 19 pueden ser un servidor, más de un servidor, distribuidos, basados en la nube o divididos en tipos específicos de funcionalidad tal como un servidor de información complementaria 52, servidores de terceros externos, un servidor de almacenamiento y reenvío 54 y un servidor de analíticas 56. Los dispositivos informáticos 20 también pueden comunicarse con los servidores de fin 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 reciben por un servidor 54 con una capacidad de almacenamiento y reenvío 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 se dispone 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) ya sea 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) localizados ya sea directa o indirectamente en un servidor de información complementaria 52. Como alternativa, 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 sin procesar (RTbD) en grandes cantidades de datos de telemáticas analíticas (ATbD) para 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 BigQuery de Google™. A continuación, los dispositivos informáticos 20 pueden acceder a las grandes cantidades de datos de telemáticas analíticas (ATbD) en tiempo real para realizar consultas y notificación de gestión de flota. El servidor 56 con capacidad analítica puede ser un único servidor de analíticas o una pluralidad de servidores de analítica 56a, 56b, y 56c.

Un ejemplo de transformación de las 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 y notificación con respectos a un fallo de comunicación de dispositivo móvil con respecto a una red de comunicaciones. Las grandes cantidades de datos de telemáticas sin procesar (RTbD) contienen al menos una localización de GPS del dispositivo móvil y vehículo asociado (información de latitud y longitud). Información adicional en forma de datos complementarios (SD) puede añadir continuación una localizació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 de vehículos 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 una localización de vehículo o dispositivo móvil en el mapa con respecto a la zona o área de comunicación 51. Si un dispositivo móvil tuviera un problema de comunicación, la zona o área de comunicación 51 puede identificarse a partir del análisis de las grandes cantidades de datos.

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

Haciendo referencia ahora a la Figura 6a, se describe una realización del constructor de grandes cantidades de datos de telemáticas analíticas 55. Expertos en la materia aprecian que el constructor de grandes cantidades de datos de telemáticas analíticas 55 puede ser un dispositivo autónomo con un microprocesador, memoria, firmware o software con capacidad de comunicación. Como alternativa, el constructor de grandes cantidades de datos de telemáticas analíticas 55 puede ser integral con un servidor de fin especial, por ejemplo un servidor de almacenamiento y reenvío 54. Como alternativa, el constructor de grandes cantidades de datos de telemáticas analíticas 55 puede asociarse o ser integral con un sistema de hardware de telemetría de vehículo 30. Como alternativa, la funcionalidad del constructor de grandes cantidades de datos de telemáticas analíticas 55 puede ser un recurso basado en la nube. Como alternativa, puede haber uno o más constructores de grandes cantidades de datos de telemáticas analí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 de grandes cantidades de datos de telemáticas analíticas 55 recibe en tiempo real las grandes cantidades de datos de telemáticas sin procesar (RTbD) en un segregador de datos. Las grandes cantidades de datos de telemáticas sin procesar (RTbD) son un registro mezclado de datos de telemáticas sin procesar e incluyen datos de vehículos sin procesar 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. Expertos en la materia aprecian 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 en datos a preservar y datos a modificar en tiempo real. Esto se realiza en una base de categoría a categoría, o como alternativa, en una base de subcategoría. Los datos a preservar se proporcionan en el formato sin procesar a un amalgamador de datos. Los datos a modificar se proporcionan a un modificador de datos. El modificador de datos obtiene datos complementarios (SD) para complementar y modificar los datos a modificar con información adicional. Los datos complementarios (SD) pueden ser residentes con el constructor de grandes cantidades de datos de telemáticas analíticas 55 o externos, por ejemplo localizados en al menos un servidor de información complementaria 52, o localizados en al menos un servidor de almacenamiento y reenvío 54 o en la nube y pueden distribuirse adicionalmente. El modificador de datos proporciona a continuación los datos a modificar y los datos complementarios al amalgamador de datos. El amalgamador de datos monta de nuevo o formatea los datos a preservar, datos a modificar y datos complementarios (SD) para construir las grandes cantidades de datos de telemáticas analíticas (ATbD) en tiempo real. Las grandes cantidades de datos de telemáticas analíticas (ATbD) pueden comunicarse a continuación en tiempo real, o enviarse por flujo continuo en tiempo real, o almacenarse en tiempo real para analítica de gestión de flota en tiempo real posterior. En una realización de la invención, las grandes cantidades de datos de telemáticas analíticas (ATbD) se comunican y envían por flujo continuo en tiempo real a un servidor de analíticas 56 que tiene acceso a la tecnología BigQuery de Google.

Haciendo referencia 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 las grandes cantidades de datos de telemáticas sin procesar (RTbD) en una pluralidad de distintos tipos o grupos de datos (1, 2, 3, n) basándose en las categorías. La pluralidad de datos a preservar se proporcionan a continuación al amalgamador de datos para montaje con los datos modificados para montaje en las grandes cantidades de datos de telemáticas analíticas (ATbD).

Haciendo referencia 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 las grandes cantidades de datos de telemáticas sin procesar (RTbD) en datos a preservar (categoría 1) y una pluralidad de distintos tipos o grupos de datos a modificar (A, B, C, n) basándose en las categorías (2, 3, 4 y 5). Por ejemplo, una categoría puede ser datos de 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 de GPS en un formato de máquina de coordenadas de latitud y longitud. Este formato de máquina diferente puede ampliarse con información legible por humanos. Los tipos de datos a modificar se proporcionan al modificador de datos y el modificador de datos obtiene una pluralidad de correspondientes tipos de datos complementarios (SD) (A, B, C, n). El modificador de datos a continuación modifica los tipos de datos a modificar con los correspondientes tipos de datos complementarios. Los datos a preservar y la pluralidad de datos modificados se proporcionan al amalgamador de datos para montaje en las grandes cantidades de datos de telemáticas analíticas (ATbD).

Expertos en la materia aprecian que puede haber unos datos a preservar, unos datos a modificar, al menos unos datos a preservar, al menos unos datos a modificar en diferentes combinaciones entre el segregador de datos y amalgamador de datos.

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

Otra realización de la invención que incluye al menos una memoria intermedia activa o cola de espera de bloqueo se describe con referencia a las Figuras 7a, 7b y 7c. Una primera memoria intermedia activa (véase 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 unos datos a modificar. En una realización de la invención, la primera memoria intermedia activa se dispone intermedia del segregador de datos y amalgamador de datos. La primera memoria intermedia activa ayuda 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 pueden estar a una tasa más constante en contraste al procesamiento de los datos a modificar y datos complementarios en el modificador de datos. Cuando se produce una diferencia en tasas de procesamiento, o diferencias en temporización, la primera memoria intermedia activa puede suavizar cargas de datos pesadas intermitentes y minimizar cualquier impacto de demanda máxima en 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.

Como alternativa, también puede disponerse una segunda memoria intermedia doble activa o cola de espera de bloqueo doble (véase la Figura 7b) con el constructor de grandes cantidades de datos de telemáticas analíticas 55. La segunda memoria intermedia doble activa puede retener temporalmente las grandes cantidades de datos de telemáticas analíticas (ATbD). Esto puede producirse cuando una petición de comunicación o envío por flujo continuo falla debido o bien a problema de red o bien excepciones con el servidor de analíticas 56. Las grandes cantidades de datos de telemáticas analíticas (ATbD) se mantienen en la segunda memoria intermedia doble activa de tal forma que los datos están disponibles y se comunican satisfactoriamente al servidor de analíticas 56 en un orden o secuencia en tiempo real. En una realización de la invención, la segunda memoria intermedia doble activa se dispone después del amalgamador de datos.

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

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

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 las grandes cantidades de datos de telemáticas sin procesar (RTbD) en tres tipos o flujos de datos. El primer tipo de datos son datos a preservar que se pasan directamente al amalgamador de datos. Un segundo tipo de datos son datos de traducción a modificar y el tercer tipo de datos son los datos de ampliación a modificar. El modificador de datos para esta realización puede ser al menos un modificador de datos.

Los datos de traducción a modificar requieren 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 a modificar. Los datos de traducción (TD) pueden ser residentes con el constructor de grandes cantidades de datos de telemáticas analíticas 55 o externos, por ejemplo localizados en al menos un servidor de traducción 53.

Los datos de ampliación a modificar requieren datos de ampliación (AD). El modificador de datos obtiene datos complementarios (SD) en forma de datos de ampliación para modificar los datos de ampliación a modificar. Los datos de ampliación (AD) puede ser residentes con el constructor de grandes cantidades de datos de telemáticas analíticas 55 o externos, por ejemplo localizados en al menos un servidor de ampliación 57. El amalgamador de datos monta de nuevo o formatea los datos a preservar, datos de traducción modificados y datos de ampliación modificados para construir las grandes cantidades de datos de telemáticas analíticas (ATbD). Las grandes cantidades de datos de telemáticas analíticas (ATbD) a continuación pueden comunicarse o enviarse por flujo continuo en tiempo real o almacenarse en tiempo real para analítica de gestión de flota en tiempo real posterior.

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 únicamente proporciona datos de traducción y datos de preservador en la transformación a grandes cantidades de datos de telemáticas analíticas (ATbD). La realización en la Figura 8c es también similar a la realización en la Figura 8a, pero el constructor de grandes cantidades de datos de telemáticas analíticas 55 únicamente proporciona datos de ampliación y datos a preservar 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). Expertos en la materia aprecian que el constructor de grandes cantidades de datos de telemáticas analíticas puede procesar datos a preservar, datos a modificar o una combinación de datos a preservar y datos a modificar.

Otro conjunto de realizaciones de la invención incluye categorías de datos complementarios de ejemplo y memorias intermedias activas. Esto se describe con referencia a las Figuras 9a, 9b y 9c. El segregador de datos procesa las grandes cantidades de datos de telemáticas sin procesar (RTbD) en tres tipos de datos. El primer tipo de datos son datos a preservar que se pasan directamente al amalgamador de datos. Un segundo tipo de datos son datos de traducción a modificar y el tercer tipo de datos son los datos de ampliación a modificar. Al menos se proporciona una memoria intermedia activa al generador de grandes cantidades de datos de telemáticas analíticas 55 para almacenar en memoria intermedia uno de o ambos de los datos de traducción a modificar y los datos de ampliación a modificar. El modificador de datos obtiene complementarios en forma de datos de traducción (TD) para modificar los datos de traducción a modificar y los datos complementarios (SD) en forma de datos de ampliación (AD) para modificar los datos de ampliación a modificar. El amalgamador de datos monta de nuevo o formatea los datos a preservar, datos de traducción modificados y los datos de ampliación modificados para construir las grandes cantidades de datos de telemáticas analíticas (ATbD) que a continuación pueden comunicarse o enviarse por flujo continuo en tiempo real o almacenarse en tiempo real para analítica de gestión de flota en tiempo real posterior.

Un ejemplo se describe con respecto a datos de GPS encontrados en las grandes cantidades de datos de telemáticas sin procesar (RTbD). Datos de GPS contienen una indicación de latitud y longitud de un vehículo o dispositivo móvil. Los datos de GPS pueden transformarse en grandes cantidades de datos de telemáticas analíticas (ATbD) de dos formas. Los datos de GPS pueden transformarse en una localización tal como una carretera, autopista, calle o dirección. A continuación un icono que representa el vehículo puede asociarse con un mapa en movimiento 50 para proporcionar una localización del vehículo. Los datos de GPS también pueden transformarse en un área o zona o célula de red 51 o múltiples áreas o zonas 51 (véase la Figura 4). A continuación el icono que representa el vehículo puede asociarse también con un área o zona de red 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 únicamente proporciona datos de traducción y datos a preservar en la transformación a grandes cantidades de datos de telemáticas analíticas (ATbD). La realización en la Figura 9c es también similar a la realización en la Figura 9a, pero el constructor de grandes cantidades de datos de telemáticas analíticas 55 proporciona datos de ampliación y datos a preservar 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 y adicionalmente incluyen tanto la primera memoria intermedia activa como la segunda memoria intermedia doble activa. La primera memoria intermedia activa se dispone en el constructor de grandes cantidades de datos de telemáticas analíticas 55 intermedia del segregador de datos y amalgamador de datos. La segunda memoria intermedia doble activa se dispone 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 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) incluye datos de categoría 1 en dos subcategorías. La primera subcategoría incluye datos de depuración y datos de número de identificación de vehículo (VIN). La segunda subcategoría incluye datos específicos de motor. Datos de categoría 2 incluyen datos de GPS y datos de categoría 3 incluyen datos de acelerómetro.

Las grandes cantidades de datos de telemáticas sin procesar (RTbD) que incluyen categoría 1 (y subcategorías), 2 y 3 se proporcionan al segregador de datos. El segregador de datos identifica datos a preservar a partir de las grandes cantidades de datos de telemáticas sin procesar (RTbD). Los datos a preservar incluyen las porciones de datos de categoría 1 (datos de depuración y datos de número de identificación de vehículo (VIN)) y los datos de acelerómetro de categoría 3. Estos datos a preservar se proporcionan directamente al amalgamador de datos.

El segregador de datos también identifica datos de traducción a modificar e incluye una porción de los datos de categoría 1 (datos específicos de motor). Los datos de traducción (TD) requeridos incluyen al menos uno de datos de códigos de fallo, datos de códigos de fallo convencionales, datos de códigos de fallo no convencionales, descripciones de fallo, descripciones de advertencias e información de diagnóstico. El modificador de datos a continuación proporciona los datos de traducción a modificar y datos de traducción (TD) en forma de datos modificados de motor.

El segregador de datos también identifica datos de ampliación a modificar e incluye los datos de categoría 2 (datos de GPS). Los datos de ampliación (AD) requeridos incluyen al menos uno de datos de código postal o código zip, datos de dirección física, datos de contacto, datos de zona de red, datos de área de red o datos de célula de red. El modificador de datos a continuación proporciona los datos de ampliación a modificar y datos de ampliación en forma de datos de GPS modificados.

El amalgamador de datos a continuación monta o formatea y proporciona las grandes cantidades de datos de telemáticas analíticas (ATbD) en tiempo real. Las grandes cantidades de datos de telemáticas analíticas (ATbD) incluyen datos de depuración, datos de número de identificación de vehículo (VIN), datos de acelerómetro, datos de motor, al menos uno de datos de códigos de fallo, datos de códigos de fallo convencionales, datos de códigos de fallo no convencionales, descripciones de fallo, descripciones de advertencias, información de diagnóstico, datos de GPS y al menos uno de datos de código postal, datos de código zip, datos de dirección física 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 para cualesquiera datos complementarios requeridos para 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 en el que 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 r ir m li r in r r m l .

continuación

Expertos en la materia aprecian que 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) pueden incluirse y transformarse en grandes cantidades de datos de telemáticas analíticas (ATbD) mediante el constructor de grandes cantidades de datos de telemáticas analíticas 55 de la presente invención.

Representación de máquina de estados

Haciendo referencia ahora a la Figuras 12a, 12b, y 12c, se describe una representación de máquina de estado de la lógica asociada con el constructor de grandes cantidades de datos de telemáticas analíticas 55. Existen cuatro estados a la lógica que operan simultáneamente y en paralelo. Puede haber adicionalmente múltiples casos de cada estado. El estado inicial es el estado de segregador de datos. La lógica del estado de segregador de datos es para filtrar, identificar y separar las grandes cantidades de datos de telemáticas sin procesar (RTbD) en datos a preservar y datos a modificar. El estado de segregador de datos espera la recepción de un registro o porción de grandes cantidades de datos de telemáticas sin procesar (RTbD). Tras la recepción, el segregador de datos procesa las grandes cantidades de datos de telemáticas sin procesar (RTbD) en o bien al menos unos datos a preservar trayectoria o bien al menos unos datos a modificar trayectoria. Las grandes cantidades de datos de telemáticas sin procesar (RTbD) en la al menos una trayectoria de datos a preservar se proporciona opcionalmente a una primera memoria intermedia activa o directamente al estado de amalgamador de datos. Las grandes cantidades de datos de telemáticas sin procesar (RTbD) en los datos a modificar trayectoria se proporcionan opcionalmente a una primera memoria intermedia activa o directamente al estado de modificador de datos. A continuación, el estado de segregador de datos espera la recepción del siguiente registro o porción de grandes cantidades de datos de telemáticas sin procesar (RTbD).

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

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

En una realización de la invención, el estado de modificador de datos tiene dos subestados, el estado de datos a traducir y el estado de datos a ampliar. El estado de datos a traducir obtiene datos a traducir para categorías particulares de datos a modificar que requieren una traducción. El estado de datos a ampliar obtiene datos a ampliar para categorías particulares de datos a modificar que requieren ampliación. Expertos en la materia aprecian que pueden añadirse otros subestados al estado de modificador de datos.

En una realización de ejemplo de la invención, la categoría 2 requiere datos a ampliar y las categorías 1b, 4 y 5 requieren datos a traducir. Datos a ampliar y datos a traducir de ejemplo se ilustran anteriormente en la Tabla 1.

La lógica del estado de amalgamador de datos es para montar, o formatear, o integrar los datos a preservar, datos a modificar y datos complementarios en las grandes cantidades de datos de telemáticas analíticas (ATbD). El estado de amalgamador de datos recibe los datos a preservar desde el segregador de datos y los datos modificados desde el estado de modificador de datos. Los datos a preservar se procesan en el formato para las grandes cantidades de datos de telemáticas analíticas (ATbD). Las grandes cantidades de datos de telemáticas analíticas (ATbD) en los datos a preservar trayectoria se proporcionan opcionalmente a una segunda memoria intermedia doble activa o directamente al estado de amalgamador de datos.

La lógica del estado de transferencia de datos es para comunicar o almacenar o enviar por flujo continuo las grandes cantidades de datos de telemáticas analíticas (ATbD) a un servidor de analíticas 56 o un recurso basado en informática en la nube. El estado de transferencia de datos recibe las grandes cantidades de datos de telemáticas analíticas (ATbD) o bien directamente desde el estado de amalgamador de datos o indirectamente desde la segunda memoria intermedia doble activa. Las grandes cantidades de datos de telemáticas analíticas (ATbD) se proporcionan a continuación al servidor de analíticas 56 o el recurso basado en informática en la nube.

Lógica y tareas de proceso

La lógica y tareas de proceso de la presente invención se describen con referencia a las Figuras 13a, 13b, 13c, 13d, 13e y 13f. La lógica y tareas de estado de segregador de datos comienza obteniendo en tiempo real 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 a preservar y al menos una categoría de datos a modificar. En una realización de la invención, existe más de una categoría de datos a preservar, y categoría de no alterar, etc. Los datos a preservar se hacen disponibles al amalgamador de datos. Los al menos unos datos a modificar se hacen disponibles al modificador de datos. La lógica y tareas de proceso puede autoescalarse según se requiera para el registro de grandes cantidades de datos de telemáticas sin procesar (RTbD). La lógica y tareas de estado de segregador de datos puede ser o bien procesamiento secuencial o bien procesamiento en paralelo o una combinación de procesamiento secuencial y en paralelo.

La lógica y tareas de proceso para la lógica y tareas de estado de modificador de datos comienza obteniendo los al menos unos datos a modificar desde el segregador de datos. Para cada uno de los al menos unos datos a modificar, se obtienen los correspondientes datos complementarios. Cada uno de los al menos unos datos a modificar se modifica con los correspondientes datos complementarios para formar al menos unos datos modificados. Los al menos unos datos modificados se hacen disponibles al modificador de datos. La lógica y tareas de proceso puede autoescalarse según se requiera para o bien los datos a modificar y/o bien los datos complementarios.

La lógica y tareas de proceso para la lógica y tareas de estado de amalgamador de datos comienza obteniendo los al menos unos datos a preservar desde el segregador de datos y los al menos unos datos modificados desde el modificador de datos. Los al menos unos datos a preservar y los al menos unos datos modificados se amalgaman para formar las grandes cantidades de datos de telemáticas analíticas. La lógica y tareas de proceso puede autoescalarse según se requiera o bien para los al menos unos datos a preservar y/o bien los al menos unos datos modificados. La lógica y tareas de estado de amalgamador de datos puede ser o bien procesamiento secuencial o bien procesamiento en paralelo o una combinación de procesamiento secuencial y en paralelo.

La lógica y tareas de proceso para la lógica de estado transferencia de datos y tareas comienza obteniendo las grandes cantidades de datos de telemáticas analíticas (ATbD) desde el amalgamador de datos. Las grandes cantidades de datos de telemáticas analíticas (ATbD) se comunican o envían por flujo continuo a un servidor de analítica o recurso basado en la nube. La lógica y tareas de proceso puede autoescalarse según se requiera para las grandes cantidades 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 diferentes vehículos 11 pueden estar operacionales en cualquier momento dado por todo el mundo en muchas zonas horarias diferentes, todos supervisando, registrando y comunicando 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 tipo de datos de telemáticas sin procesar (véase la Tabla 1) también pueden variar enormemente dependiendo de las configuraciones específicas de cada vehículo 11 (sistema de hardware de telemetría vehicular 30, expansores de E/S inteligentes 50, dispositivos 60, módulos de Bluetooth 45 y balizas de Bluetooth 21 asociadas con una pluralidad de objetos). Esto resulta en una velocidad, temporización, variedad y cantidad de grandes cantidades de datos únicas de datos de telemáticas sin procesar que colectivamente forman las grandes cantidades de datos de telemáticas sin procesar (RTbD) que entran en el segregador de datos del constructor de grandes cantidades de datos de telemáticas analíticas 55. Estos se denominan colectivamente como una carga de grandes cantidades de datos de telemáticas sin procesar (RTbD).

Existen también muchos diferentes tipos de datos complementarios (SD) requeridos por el modificador de datos disponibles de muchas localizaciones diferentes y fuentes remotas. Los datos complementarios (SD) también dependen de la porción o mezcla de grandes cantidades de datos de telemáticas sin procesar (RTbD). Esto resulta en otra velocidad, temporización, variedad y cantidad de grandes cantidades de datos únicas de datos complementarios (SD) (véanse los datos a ampliar y datos a traducir de la Tabla 1) requeridos por el modificador de datos. Estos se denominan colectivamente como una carga de datos complementarios.

La comunicación o envío por flujo continuo de las grandes cantidades de datos de telemáticas analíticas (ATbD) a un servidor de analíticas 56 o un recurso basado en la nube también depende de la capacidad del servidor de analíticas 56 o de los recursos basados en la nube para recibir las grandes cantidades de datos de telemáticas analíticas (ATbD). Esto resulta en otra velocidad, temporización, variedad y disponibilidad de comunicar o enviar por flujo continuo las grandes cantidades de datos de telemáticas analíticas (ATbD). Estos se denominan colectivamente como una carga de grandes cantidades de datos de telemáticas analíticas (ATbD).

El resultado final es una pluralidad de desequilibrios potenciales para la carga, velocidad, temporización, variedad y cantidad de grandes cantidades 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 ser capaces de tratar en tiempo real este desequilibrio en tiempo real.

En una realización de la invención, este desequilibrio se resuelve mediante la disposición única de los conductos, filtros y tareas asociados con el constructor de grandes cantidades de datos de telemáticas analíticas 55. Esta disposición única permite equilibrio de carga y escalado cuando se producen desequilibrios en el sistema. Por ejemplo, los conductos, filtros y tareas pueden aumentarse o disminuirse dinámicamente (casos concurrentes) basándose en la carga en tiempo real. Los datos se normalizan en formatos específicos para cada uno de los finitos estados, 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 a preservar, el formato de datos a modificar, el formato de datos a ampliar (AD), formato de datos de traducción (TD) y el formato de grandes cantidades de datos de telemáticas analíticas (ATbD). Además, se proporciona una estructura de conductos única para el constructor de grandes cantidades de datos de telemáticas analíticas 55 para equilibrar la carga en el sistema. Las grandes cantidades de datos de telemáticas sin procesar entran en el constructor de grandes cantidades de datos de telemáticas analíticas a través de un primer conducto al segregador de datos. El segregador de datos a continuación pasa datos a través de al menos dos conductos como datos a preservar y datos a modificar. El conducto de datos a modificar puede incluir adicionalmente conductos adicionales (A, B, C, n). Los conductos de datos a modificar se introducen en el modificador de datos con los correspondientes conductos de datos complementarios (SD). Los conductos de datos modificados y los datos a preservar se introducen en el amalgamador de datos y finalmente, las grandes cantidades de datos de telemáticas analíticas (ATbD) se introducen en el conducto de comunicación o flujo continuo. Esta arquitectura de conductos específicos de telemáticas permite ejecutar en paralelo y múltiples casos del estado de segregador de datos, el estado de modificador de datos, el estado de amalgamador de datos y el estado de flujo continuo de datos que habilitan que el sistema extienda la carga y mejore el caudal del constructor de grandes cantidades de datos de telemáticas analíticas 55. Esto también ayuda con el equilibrio del sistema en situaciones en las que los datos, por ejemplo, grandes cantidades de datos de telemáticas sin procesar (RTbD) y los datos complementarios (SD) no están en la misma localizació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 la segunda memoria intermedia activa o bien solas o en combinación. La primera memoria intermedia activa trata el desequilibrio entre las grandes cantidades de datos de telemáticas sin procesar (RTbD) y los datos complementarios (SD). La segunda memoria intermedia activa trata el desequilibrio potencial cuando se comunican o envían por flujo continuo las grandes cantidades de datos de telemáticas analíticas (ATbD) a un servidor de analíticas 56 o un recurso basado en la nube. Las memorias intermedias pueden escalar ascendente o descendentemente 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 informáticos de telemáticas única y específica.

El estado de segregador de datos, lógica, proceso y tareas se ocupan automáticamente de escalabilidad de las grandes cantidades de datos de telemáticas sin procesar (RTbD) y tareas de procesamiento asociadas para filtrar los datos en datos a preservar y datos a modificar. Esto incluye tanto escalar ascendentemente como descendentemente dependiendo de la correspondiente carga requerida por las grandes cantidades de datos de telemáticas sin procesar (RTbD) y la cantidad de procesamiento requerido para segregar porciones de los datos en datos a preservar o datos a modificar. Casos adicionales del estado de segregador de datos, lógica, proceso y tareas pueden iniciarse o detenerse automáticamente de acuerdo con los requisitos de carga, demanda o comunicación.

El estado de modificador de datos, lógica, proceso y tareas se ocupan automáticamente de la escalabilidad con los datos complementarios (SD). Esto incluye tanto escalar ascendentemente como descendentemente dependiendo de la correspondiente carga requerida por los datos complementarios (SD) y la cantidad de procesamiento requerido para modificar cada dato a modificar. Casos adicionales del estado, lógica, proceso y tareas de modificador de datos pueden iniciarse o detenerse automáticamente de acuerdo con los requisitos de carga, demanda o comunicación.

El estado, lógica, proceso y tareas de amalgamador de datos se ocupan automáticamente de la escalabilidad con los datos a preservar, datos modificados y capacidad de comunicar o enviar por flujo continuo las grandes cantidades de datos de telemáticas analíticas (ATbD) a un servidor de analíticas 56 o recurso de informática basada en la nube. Casos adicionales del estado, lógica, proceso y tareas de amalgamador de datos pueden iniciarse o detenerse automáticamente de acuerdo con los requisitos de carga, demanda o comunicación.

El constructor de grandes cantidades de datos de telemáticas analíticas 55 habilita percepción en tiempo real basándose en las grandes cantidades de datos de telemáticas analíticas en tiempo real. Por ejemplo, los datos pueden aplicarse para supervisar el número de dispositivos de Geotab GO que conectan en la actualidad al servidor de fin especial 19 y comparar ese con el número de GO dispositivos que se espera que estén conectado en cualquier momento dado durante el día; o ser capaces de usar las grandes cantidades de datos de telemáticas analíticas en tiempo real para supervisar los dispositivos GO que están conectando con su servidor de fin especial 19 desde cada proveedor de red por satélite o celular. Usando estos datos, los gestores son capaces determinar si una portadora de red particular está teniendo problemas de notificación proactiva con clientes que puede verse afectada por la interrupción de la portadora.

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

A continuación se describe el sistema de supervisión de fallo de comunicación de grandes cantidades de datos de telemáticas con respecto a la Figura 4 y la Figura 11. Cada dispositivo móvil se comunica con el dispositivo remoto en forma de grandes cantidades de datos de telemáticas sin procesar (RTbD). Estos datos incluyen datos de GPS que se identifican para modificar. La modificación incluye datos de ampliación en forma de códigos postales, o códigos ZIP, o dirección física, o nombres de contactos o direcciones para permitir la asociación de una localización de vehículo en un mapa 50. La modificación también incluye datos de ampliación en forma de área de red o zonas de red o células de red 51 para permitir la asociación de una localizació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 ampliación son un número de identificación de célula usado para identificar una estación transceptora base o sector de una estación transceptora base dentro de un código de área de localización. El número de identificación de célula se refiere a GSM, CDMA, UMTS, LTE, WiFi y otras formas de las redes de comunicación. Además, los datos de ampliación pueden incluir adicionalmente códigos de red de servicio móvil y el número de identificación de la portadora u operador. Los números de identificación están disponibles desde un número de diferentes bases de datos y proveedores de servicios.

Como se ilustra en la Figura 4, el mapa 50 ilustra un número de iconos representativos de vehículos (A a K) que se mueven en tiempo real. Existen tres zonas o áreas de red 51 también superpuestas en el mapa 50. En una zona o área de comunicación 51, está el vehículo D. En otra zona o área de comunicación 51, están los vehículos A, B, C, E y H. En otra zona o área de comunicación 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 o área de comunicación 51.

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

Haciendo referencia ahora a la Figura 14a, se describe a continuación una representación de estado para determinar un fallo de comunicación basándose en comunicación esperada y comunicación real. Existen dos estados primarios, el estado de determinación de fallo de comunicación de dispositivo remoto y el estado de modo de comunicación esperado de dispositivo móvil. El estado de modo de comunicación esperado de dispositivo móvil incluye un subestado de modo activo y un subestado de modo inactivo. El estado de modo inactivo, representativo de modos de ahorro de potencia en niveles para el dispositivo móvil adicionalmente incluyen dos subestados, un estado de inactividad y un estado de inactividad profunda.

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

El modo activo se produce cuando un dispositivo móvil está totalmente encendido y operacional. 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 Expertos en la materia aprecian que la primera frecuencia de comunicación puede incluir otros valores diferentes.

El modo inactivo se produce cuando un dispositivo móvil se apaga en al menos un modo de ahorro de potencia. El subestado o modo de inactividad es un primer modo de ahorro de potencia y proporciona una segunda frecuencia periódica de comunicación, o 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 expertos en la materia también aprecian que la segunda frecuencia de comunicación puede incluir otros valores diferentes. El subestado o modo de inactividad profunda es un segundo modo de ahorro de potencia y proporciona una tercera frecuencia periódica de comunicación, o 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 expertos en la materia también aprecian que la tercera frecuencia de comunicación puede incluir otros valores diferentes.

Las tres frecuencias de comunicaciones proporcionan tres marcos temporales conocidos de comunicación esperada, o umbrales para el dispositivo remoto. La comunicación esperada podría ser en forma de una señal, datos, y/o un mensaje dependiendo 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 fallo de comunicación de dispositivo remoto rastrea y suma las conexiones esperadas basándose en los estados de modo de comunicación esperada de dispositivo móvil y como se ilustra en la Tabla 2 puede incluir una pluralidad de dispositivos móviles operando con la primera frecuencia de comunicación, o una pluralidad de dispositivos móviles operando con la segunda frecuencia de comunicación, o una pluralidad de dispositivos móviles operando con la tercera frecuencia de comunicación así como combinaciones de la primera, segunda y tercera frecuencias de comunicación.

Tabla 2: Comunicación es erada de eem lo ara un número de dis ositivos móviles.

Haciendo referencia ahora a la Figura 14b, se describe el procesamiento de datos para determinar un fallo de comunicación basándose en comunicación esperada y un periodo de comunicación real. Diferentes tipos y categorías de datos se preprocesan en tiempo real para crear las grandes cantidades de datos de telemáticas analíticas (ATbD) usadas para determinar un fallo de comunicación de red. El preprocesamiento puede ser con un servidor de fin especial 19, u otro dispositivo informático 20. El registro de datos de dispositivos GO (RTbD) son datos históricos durante un periodo de tiempo e incluye al menos unos datos de GPS y una indicación del estado de vehículo. Los datos complementarios (SD) incluyen datos de localización y datos de red. El registro de datos de dispositivos GO (RTbD) se combina con los datos complementarios (SD) para formar los datos de analítica (ATbD). Los datos complementarios pueden obtenerse 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 el estado de vehículo datos es una indicación de encendido o apagado de motor u otra indicación representativa de un modo activo y modo inactivo para el dispositivo móvil. En una realización de la invención, los datos de localización pueden incluir al menos uno de un código postal, un código ZIP, una dirección física, una indicación de carretera, una indicación de autopista, un nombre, información de contacto o un número de teléfono. En una realización de la invención, la red datos 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 procesamiento de datos puede incluir una capacidad de autoescalado para equilibrar el envío por flujo continuo en tiempo real de los datos. En las realizaciones de la invención, la capacidad de autoescalado puede ser una memoria intermedia, una memoria intermedia doble o una combinación de una memoria intermedia y memoria intermedia doble.

Haciendo referencia ahora a la Figura 15, se describe la lógica de determinación de periodo de comunicación esperada de dispositivo móvil. El dispositivo móvil detecta el estado de 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 vehicular 30 y el bus de comunicaciones de red de vehículo 37. Después de que se ha detectado el estado de vehículo, el estado de vehículo se comprueba para determinar si el estado es verdadero o falso. En una realización de la invención, el estado de vehículo es un código para "encendido activado" y si el estado es "activado", la comprobación es verdadero o si el estado es "desactivado", la comprobación es falso. Si la comprobación es verdadero, a continuación se establece el modo activo para indicar un primer periodo de comunicación.

Si la comprobación es falso, a continuación se establece el modo inactivo. Para el caso en el que existen una pluralidad de modos de ahorro de potencia, se hace una comprobación posterior con respecto a un umbral de periodo inactivo. Si el umbral no se ha alcanzado (indicativo de un primer modo de ahorro de potencia), a continuación se establece un segundo periodo de comunicación. Si el umbral se ha alcanzado (indicativo de un segundo modo de ahorro de potencia), a continuación se establece un tercer periodo de comunicación.

Una vez que se han establecido o reestablecido el primero o segundo o tercer periodos de comunicación basándose en la lógica, el dispositivo móvil comunica con un dispositivo remoto basándose en uno de los periodos de comunicación como una comunicación esperada. El estado de vehículo se comprueba para determinar si el estado de vehículo ha cambiado. A continuación, la lógica de determinación de periodo de comunicación esperada de dispositivo móvil se ejecuta en cada dispositivo móvil. En una realización de la invención, la lógica de determinación de periodo de comunicación esperada de dispositivo móvil es también un primer proceso asíncrono.

Haciendo referencia ahora a la Figura 16a, se describe a continuación la lógica de determinación de activo/inactivo de dispositivo remoto para cada dispositivo móvil. El dispositivo remoto establece un marco temporal de muestra o temporización para comprobar y determinar la presencia de uno o más fallos de comunicación. A continuación, el dispositivo remoto recibe registros de dispositivo móvil de datos desde cada uno de los dispositivos remotos dentro del marco temporal de muestra. Para cada registro de datos de dispositivo, el registro anterior se decodifica para identificar el indicador de estado de vehículo a partir del registro. Si el estado de vehículo es verdadero, a continuación el dispositivo remoto determina que el dispositivo móvil está en un modo activo. Si el estado de vehículo es falso, a continuación el dispositivo remoto determina que el dispositivo móvil está en un modo inactivo. El dispositivo remoto puede a continuación rastrear cada dispositivo móvil y el correspondiente estado de activo o inactivo.

Haciendo referencia ahora a la Figura 16b, se describe la lógica de determinación de comunicación esperada de dispositivo remoto para cada dispositivo móvil. El dispositivo remoto recibe una pluralidad de registros de dispositivo móvil de datos dentro de la muestra de marco temporal de comunicación. Para cada registro de datos, se determina el estado de vehículo. Si el estado de vehículo es verdadero, a continuación el dispositivo móvil está en un modo activo con una comunicación esperada de un primer periodo de frecuencia. Si el estado de vehículo es falso, a continuación se comprueba el umbral de periodo inactivo. Si el umbral no se ha alcanzado, a continuación el dispositivo móvil está en un modo inactivo con una comunicación esperada de un segundo periodo de frecuencia. Si el umbral se ha alcanzado, a continuación el dispositivo móvil está en un modo inactivo con una comunicación esperada de un tercer periodo de frecuencia. El dispositivo remoto rastrea cada modo de dispositivo móvil, comunicación esperada y periodo de frecuencia para usar y comparación con recepción del siguiente conjunto de registros de dispositivo móvil en la siguiente muestra de marco temporal de comunicación para 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 de activo/inactivo de dispositivo remoto para cada dispositivo móvil y el dispositivo remoto periodo de lógica de determinación de comunicación esperada son también un segundo proceso concurrente asíncrono.

Haciendo referencia ahora a la Figura 16c, se describe la lógica de determinación de fallo de comunicación real y esperada de dispositivo remoto. Cuando se ha alcanzado el periodo de muestra de marco temporal de comunicación, determinar 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 periodo de frecuencia más el número de dispositivos móviles en un modo inactivo con una conexión esperada de un segundo periodo de frecuencia. Como alternativa, 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 periodo de frecuencia.

Se hace una comparación con respecto al número total de conexiones reales con el número de dispositivos móviles que están conectados en la actualidad. Cuando el número total de conexiones esperadas es igual a el número total de conexiones reales, no hay fallo con las comunicaciones. Cuando el número total de conexiones esperadas no es igual a el número total de conexiones reales, hay un fallo con las comunicaciones. Cuando hay un fallo con las comunicaciones, para cada dispositivo móvil que no se conectó, acceder a las coordenadas de GPS ampliadas a partir de los datos y comparar con las coordenadas con una zona, o área o célula de red para determinar la localización del fallo en la red.

Haciendo referencia ahora a la Figura 17, se describe la lógica de determinación de fallo de comunicación de red de dispositivo remoto. Para cada determinación de fallo de comunicación asociada con un dispositivo móvil, determinar las coordenadas de GPS ampliadas a partir de los datos para el dispositivo móvil que se esperaba comunicar y no comunicó. Determinar el área o zona o célula de red basándose en las coordenadas de GPS ampliadas a partir de los datos. Como alternativa, determinar el área o zona o célula de red basándose en las coordenadas de GPS del registro de datos y datos complementarios o datos ampliados. Correlacionar la localización de dispositivo móvil basándose en las coordenadas de GPS con el área o zona o célula de red basándose en las coordenadas de GPS del dispositivo móvil o como alternativa las coordenadas de GPS y los datos complementarios o datos ampliados. Proporcionar una indicación de fallo en relación con cada dispositivo móvil que no comunicó y el área o zona o célula de red. Repetir para cada dispositivo móvil que no comunicó cuando se esperaba que comunicase.

La indicación de fallo puede ser en forma de una indicación gráfica en el mapa 50 que identifica el dispositivo o dispositivos móviles y el área o zona o célula de red asociada. Como alternativa, la indicación de fallo puede ser un mensaje de texto o un mensaje de audio indicando el fallo y área o zona o célula de red o informe asociado.

Sumario

En resumen, el sistema de identificación de fallo de comunicación de red de grandes cantidades de datos de telemáticas incluye un número de componentes informáticos especializados basándose en hardware, firmware, software, dispositivos móviles, dispositivos remotos, tecnología de telemáticas y tecnología de telecomunicaciones. Realizaciones de la presente invención, incluyendo los dispositivos, sistema y métodos, individual y/o colectivamente proporcionan uno o más efectos técnicos. Capacidad para proporcionar percepción comercial más profunda y análisis en tiempo real basándose en la disponibilidad más rápida de las grandes cantidades de datos de telemáticas analíticas en tiempo real. Mejorar el tiempo de respuesta de determinación de fallo de comunicación de red basándose en acceso en tiempo real a grandes cantidades de datos de telemáticas analíticas en tiempo real (ATbD). Acceso más rápido a grandes cantidades de datos de telemáticas analíticas (ATbD) y un tiempo de ciclo más corto a información de fallo 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 soportar analíticas de determinación de fallo de comunicación de red. Grandes cantidades de datos de telemáticas en tiempo real que pueden incorporar datos de traducción y datos a modificar 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 puede incorporar adicionalmente datos de ampliación y datos a modificar 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, identificar problemas de determinación de fallo 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 específicas y requisitos para tipos de datos específicos contenidos en los registros.

Mientras la presente invención se ha descrito con respecto a las realizaciones no limitantes, debe apreciarse que la invención no se limita a las realizaciones divulgadas. Expertos en la materia entienden que la invención divulgada se concibe para cubrir diversas modificaciones y disposiciones equivalentes incluidas dentro del alcance de las reivindicaciones adjuntas. Por lo tanto, la presente invención no debería limitarse por ninguna de las realizaciones descritas.

Claims

REIVINDICACIONES

1. Un método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas para un sistema que comprende al menos un dispositivo móvil conectado a un sistema de hardware de telemetría vehicular (30) y al menos un dispositivo remoto (19, 20), comprendiendo el método

al menos un primer proceso concurrente y al menos un segundo proceso concurrente,

determinando dicho primer proceso concurrente, a través de dicho al menos un dispositivo móvil (30), un modo activo o un modo inactivo de dicho al menos un dispositivo móvil (30) detectando un estado de vehículo, estableciendo un periodo de comunicación para comunicar con dicho al menos un dispositivo remoto (19, 20), y comunicando al menos uno de una señal, datos o mensaje a dicho al menos un dispositivo remoto (19, 20) dentro de dicho periodo de comunicación,

recibiendo dicho al menos un segundo proceso concurrente, a través de dicho al menos un dispositivo remoto (19, 20), desde dicho al menos un dispositivo móvil (30) dicha al menos una señal, datos o mensaje y determinando a partir de los mismos un modo activo o un modo inactivo y un correspondiente periodo de comunicación para cada uno de dicho al menos un dispositivo móvil (30), y comparando, dentro de un marco temporal de determinación de fallo de comunicación, el número de comunicaciones esperadas de dicho al menos un dispositivo móvil con el número de comunicaciones reales de dicho al menos un dispositivo móvil para indicar la presencia de un fallo de comunicación cuando el número esperado es diferente del número real para cada uno de dicho al menos un dispositivo móvil (30) que comunicó.

2. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 1, en el que dicha detección de un estado de vehículo se basa en un estado de encendido de un vehículo.

3. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 1, en el que dicho estado de vehículo proporciona una indicación para establecer un modo activo.

4. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 3, en el que dicho modo activo incluye una primera comunicación periódica para comunicar con dicho al menos un dispositivo remoto (19, 20).

5. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 4, en el que dicha primera comunicación periódica proporciona un primer periodo de comunicación esperada, preferentemente dicho primer periodo de comunicación esperada es de 100 segundos.

6. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 1, en el que dicho estado de vehículo proporciona una indicación para establecer un modo inactivo.

7. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 6, en el que dicho modo inactivo incluye una segunda comunicación periódica para comunicar con dicho al menos un dispositivo remoto (19, 20).

8. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 7, en el que dicha segunda comunicación periódica establece un segundo periodo de comunicación esperada, preferentemente dicho segundo periodo de comunicación esperada es de 1800 segundos.

9. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 6, en el que dicho modo inactivo incluye una tercera comunicación periódica para comunicación con dicho al menos un dispositivo remoto (19, 20).

10. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 9, en el que dicho tercer periodo de comunicación periódica proporciona un tercer periodo de comunicación esperada, preferentemente dicho tercer periodo de comunicación esperada es de 86.400 segundos.

11. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 6, en el que dicho modo inactivo incluye un segundo periodo de comunicación esperada y un tercer periodo de comunicación esperada.

12. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 11, en el que dicho segundo periodo de comunicación esperada y dicho tercer periodo de comunicación esperada se basan en un tiempo de 86.400 segundos, tras superar dicho tiempo de 86.400 segundos pasando de dicho segundo periodo de comunicación esperada a dicho tercer periodo de comunicación esperada.

13. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 1, en el que un estado de encendido de un vehículo contenido en dicha señal, o datos, o mensaje determina un modo activo o modo inactivo.

14. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 1, en el que dicho modo activo incluye una primera comunicación periódica para comunicar con dicho al menos dispositivo remoto (19, 20).

15. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 14, en el que dicha primera comunicación periódica proporciona un primer periodo de comunicación esperada, preferentemente dicho primer periodo de comunicación esperada es de 100 segundos.

16. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 1, en el que dicho modo inactivo incluye una segunda comunicación periódica para comunicar con dicho al menos un dispositivo remoto (19, 20).

17. El sistema de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 16, en el que dicha segunda comunicación periódica proporciona un segundo periodo de comunicación esperada, preferentemente dicho segundo periodo de comunicación esperada es de 1800 segundos.

18. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 1, en el que dicho modo inactivo incluye una tercera comunicación periódica para comunicación con dicho al menos un dispositivo remoto (19, 20).

19. El método de determinación de fallo de comunicación de grandes cantidades de datos de telemáticas de acuerdo con la reivindicación 18, en el que dicha tercera comunicación periódica proporciona un tercer periodo de comunicación esperada, preferentemente dicho tercer periodo de comunicación esperada es de 86.400 segundos.