Las nuevas tendencias en el desarrollo de modelos de negocio, basados en satisfacer necesidades cada vez más especializadas y con un conocimiento cada vez más profundo del cliente sobre sus derechos y la evolución de las tecnologías de la información, hacen que las empresas requieran procesar cada vez más un número mayor de datos, procesarlos en tiempo real y activar de forma automática acciones que soporten el negocio.
En este artículo, presentaremos de forma global un escenario del modelo de negocio que se está implantando y demandando cada vez más en el mercado de los seguros de coches a nivel mundial, usaremos el modelo “Pay as you Drive ”, el cual se presenta como una opción a la forma tradicional en cómo los clientes pagan por los servicios contenidos en el contexto de la conducción de un vehículo. Nos enfocaremos en la captura de los datos producidos por el conductor durante su conducción, la recopilación y el tratamiento de los mismos que permitan crear un perfil.
“Smart Driving Monitor” será el nombre que usaremos a lo largo de este artículo para referirnos a la demo que realizamos usando la herramienta de IBM Decision Server Insights (DSI) para dar soporte a una solución del tipo “Pay as you Drive”.
La solución
Cada vez es más común encontrarnos en entornos en los que la captura de datos y su procesamiento en tiempo real es vital para soportar el modelo de negocio, donde la interacción entre diversos dispositivos requiere ser integrados para dar valor y soportar la prestación de un servicio en el que una respuesta inmediata o el inicio inmediato de una acción de forma automática es requerida.
Si analizamos el contexto de la conducción de un vehículo, podríamos identificar una cantidad de dispositivos con impacto directo o indirecto en el vehículo que tienen influencia sobre el conductor, cuya afectación podría presentarse en momentos puntuales o continuamente. Algunos de éstos pueden ser:
Directos
- Volante
- Pedal de aceleración/freno
- Embrague
- Otros
Indirectos
- Radio
- Teléfono móvil
- Otros
Lograr capturar los datos de la mayoría de los dispositivos que están presentes cuando una persona conduce puede llevar a conocer de forma veraz lo que motivó una situación o simplemente crear un perfil de su conducción. En la demo hemos desarrollado una solución que, mediante la captura de eventos producidos durante el viaje (posición, velocidad, aceleraciones medias, máximas y otros), es capaz de crear perfiles de conducción basándose en el comportamiento del conductor, la visión del tráfico, la anticipación y el exceso/falta de velocidad, que pueden ser utilizados tanto para ajustar la tarifa del servicio de seguro que se presta al coche (los buenos conductores verán como baja) como ayudar al conductor a mejorar su estilo de conducción.
Hemos utilizado la herramienta de IBM llamada Decision Server Insights (DSI), que es un framework para el manejo masivo de eventos complejos con capacidad de razonamiento temporal y procesamiento geoespacial, que trata de una manera natural conceptos espaciales sin necesidad de hacer desarrollos específicos para el procesado de dicha información; incluye igualmente reglas de negocio, análisis predictivo en tiempo real y la posibilidad de integrar funcionalidades de nuevos desarrollos a medida mediante el uso de la arquitectura OSGI.
El uso de DSI permitió llevar a cabo un desarrollo ordenado y escalable de acuerdo a los requerimientos que se iban presentando, brindándonos entre otras cosas, la posibilidad de integrar componentes especializados y desarrollados con arquitectura OSGI para complementar la funcionalidad. Por ejemplo, la lógica de datos geoespacial para la gestión de información de las carreteras está contenida en un componente específico y especializado.
La solución “Smart Driving Monitor” (SDM) que hemos desarrollado para esta demo se basó en la captura de diversos datos provenientes del entorno de la conducción utilizando una aplicación instalada en el teléfono móvil del usuario como el generador de eventos que, mediante el uso de sus distintos sensores, permite localizar al vehículo en un punto geográfico específico, conocer los cambios de ubicación e identificar los cruces que ejecuta el conductor (bruscos o no bruscos), así como otro tipo de información que cruzada con datos de sistemas externos, crean una matriz de información que permite conocer el estado actual de una vía desde el punto de vista meteorológico y de incidencias.
Monitorización viaje
Básicamente las fuentes de datos de las que se alimenta la solución Smart Driving Monitor son: dispositivo móvil para captura de datos dentro del contexto de la conducción, servicio de la Dirección General de Tráfico y Agencia Estatal de Meteorología para nutrir de datos la vía y conocer su estado real en todo momento.
Esquema general fuentes de datos.
Algunas aplicaciones prácticas destacables que hemos desarrollados en la demo son:
Atención inmediata a una Incidencia durante la conducción
Teniendo acceso a los datos de localización y monitorización en tiempo real del vehículo, las incidencias producidas durante la conducción podrían ser atendidas de forma inmediata mediante la ejecución de acciones desencadenadas del cumplimiento de ciertos patrones. Por ejemplo, si un vehículo sufre una avería que requiere la atención de la compañía aseguradora o la intervención de alguna autoridad, el Smart Driving Monitor es capaz de establecer el contacto inicial, bien sea con un call center o inmediatamente a las autoridades (dependiendo de la gravedad) para que sea atendida dicha incidencia.
Publicidad Geoespacial
La implementación de publicidad localizada es viable, ya que con la ubicación geoespacial del vehículo y los comercios que tiene a su alrededor en el momento de detener el vehículo, al conductor se le pueden ofrecer los servicios comerciales de la zona y ofertas que puedan ser de su interés a partir del análisis de su perfil.
Básicamente sería necesario cruzar ubicación con perfil de conducción y la publicidad del comercio cuya definición se ajuste al conductor.
Acciones Predictivas
Con la disposición de los datos provenientes de otros dispositivos dentro del entorno de la conducción como puede ser: radio, teléfono móvil, smartwatch (pulsómetro), otros; el Smart Driving Monitor a través del análisis de patrones, es capaz de predecir la ocurrencia de una incidencia a partir de una acción del conductor. Por ejemplo, si entre los dispositivos que utiliza el conductor se encuentra un pulsómetro y en un momento dado se comienza a registrar una frecuencia cardiaca anómala (arritmia cardiaca) de acuerdo a lo que normalmente presenta, se puede estar ante la posibilidad de un desvanecimiento, con lo que habría que actuar, o en caso de que sea muy tarde para tomar una acción, identificar en investigación a posteriori que ésta pudo haber sido la causa de la incidencia producida.
También podríamos implementar el caso de mantenimiento predictivo en el que, basándonos en las especificaciones técnicas del vehículo, alguna pieza requiera reemplazo. Para ello podemos ayudarnos de dispositivos, por ejemplo, instalados en los frenos que, tras el análisis comparativo de la telemetría entregada por éstos y la especificación técnica del vehículo, se deduzca que es necesario realizar una operación de mantenimiento.
Forense
Quizá uno de los problemas más frecuentes que se pueden encontrar en el contexto de la conducción es demostrar con datos reales la causa que inicia un evento para buscar responsabilidades. Con esto me refiero a por ejemplo, en caso de que un conductor tenga un accidente durante la marcha se tenga que buscar las causas del incidente.
En el caso de buscar la causa que conllevó al accidente, pongámonos como ejemplo que el conductor se ha salido de la vía y con ello provocado el volcado del vehículo. Analizando la telemetría del coche y del conductor se podría identificar que un instante antes de producirse la salida de la vía el conductor contestó una llamada telefónica al móvil. Esta investigación forense podría compararse, de algún modo, con el análisis de la caja de negra de los aviones.
Análisis forense viaje
Otro caso, puede ser el quebranto de alguna condición/ley, en la que tenemos el ejemplo de las vías de circulación declaradas por el conductor al contratar la póliza. Cuando el conductor contestó el cuestionario en el que se le preguntaba sobre los tipos de vías frecuentes que utilizaría, nunca se refirió a vías forestales o quizá declaró que no saldría de cierta zona geográfica para beneficiarse de los precios que ofrece conducir únicamente por la ciudad. Mediante la ubicación del vehículo contrarrestado con el registro geoespacial de vías, se puede identificar donde está o ha estado circulando el vehículo y conocer el tipo de vía.
Monitorización límite geográfico
Perfilado del Conductor
Basándose en el análisis de los datos producidos en el contexto de la conducción (aceleración, desaceleración, cruce, otros), y contrastado con criterios/reglas, siempre que el conductor finalice un viaje, se creará un perfil que puntuará su forma de conducir, que será utilizado para clasificarlo y aplicarle el coste del uso de la póliza en el viaje realizado.
Básicamente un conductor cuyos parámetros de comportamiento se encuentren dentro de un rango definido verá como la factura por el uso de la póliza en sus viajes será menor a la de un conductor cuyo perfil de conducción está fuera de los parámetros. Por ejemplo, un conductor que tenga como práctica habitual realizar cruces bruscos verá como por aumentar su nivel de probabilidad a tener una colisión con otro vehículo o peatón su factura presentará un incremento.
En la conclusión del viaje se lleva a cabo una acumulación de los datos producidos durante la conducción. Dichos datos que han permanecido en memoria de forma activa pasan a ser procesados mediante la aplicación de una serie de reglas con los criterios que la empresa aseguradora tenga definidos para dar una puntuación a su viaje.
En la siguiente gráfica se puede visualizar un ejemplo de la conclusión del viaje enviado a la aplicación móvil del conductor.
Retención del cliente
Un cliente contento con un servicio personalizado y a la medida de sus necesidades hace que aumente su nivel de fidelidad hacia la empresa aseguradora, relación que gracias a la flexibilidad de la arquitectura con la que ha sido desarrollado el Smart Driving Monitor, permite maximizar su uso con la actualización de nuevas funcionalidades, promociones, e incluso aumentar el nivel de datos que la empresa utiliza para atender mejor al cliente, integrándolo con otros sistemas internos como podría ser: ERP, CRM y otros.
Como se pudo apreciar, la integración en un único lugar de todos los datos provenientes del contexto de la conducción, y el cruce de éstos con otros procedentes de fuentes externas e incluso de sistemas internos de la compañía aseguradora, permiten crear una gran cantidad de funcionalidades y ofrecer un mejor servicio al cliente.
¿Cómo hemos implementado la demo Smart Driving Monitor? ¿Cuál es la definición del Smart Driving Monitor desde un punto de vista más técnico? Si quieres conocer los pormenores técnicos, te invito a que continúes con la lectura.
Arquitectura de la Solución
Como ya hemos comentado anteriormente, utilizamos la herramienta de IBM Decision Server Insights (DSI) como plataforma para soportar la demo del Smart Driving Monitor, la cual entre otras bondades, maneja de forma natural conceptos espaciales, razonamiento temporal, escalabilidad y capacidad de expansión según se vaya requiriendo desde el punto de vista físico (añadiendo nuevos servidores, creando datagrids) como lógico (mediante la integración con otros desarrollos específicos que pueden ser integrados basados en la arquitectura OSGI).
La estructuración de la información y su procesado por parte de DSI se organiza en torno a 3 conceptos distintos: Eventos, entidades y agentes [1].
Basándonos en dicha estructura hemos creado una serie de entidades que son la representación lógica de los objetos presentes dentro del contexto de la solución (en nuestro caso la solución es el backend del Smart Driving Monitor), identificando las siguientes:
Entidades funcionales
- Vehículo
- Cliente
- Póliza
- Viaje
Entidades funcionales orientadas a ofertas comerciales
- Ofertas comerciales
- Negocios
Entidades funcionales orientadas al proceso de petición de ayuda
- Taller asociado
Estas entidades por sí solas no tienen valor, por lo que requieren ser actualizadas y alimentadas por sistemas externos, lo que se lleva a cabo mediante la publicación de servicios REST, para lo que se han creado dos endpoints: uno a través del cual la aplicación del dispositivo móvil envía los eventos allí producidos, y otro utilizado para la actualización en tiempo real del estado climatológico y de incidencias de las carreteras (esta actualización la realiza un servicio externo a DSI).
Endpoints backend
Siendo los eventos esperados en el endpoint asociado a la aplicación móvil los siguientes:
- Inicio de trayecto
- Actualización de estado del trayecto
- Petición de ayuda
- Fin de trayecto
Una vez obtenidos los datos provenientes del entorno operativo del Smart Driving Monitor, éstos, dependiendo del uso que se les vaya a dar, pasan a través de diversos flujos en los cuales son sometidos a evaluaciones a través de reglas. A continuación se describen los flujos y la implementación que se ha realizado de los mismos desde el punto de vista del servidor central.
Perfilado del Conductor
El perfilado del conductor es la principal funcionalidad en la demo del SDM. Para el perfilado del conductor solamente se utilizan 3 tipos distintos de eventos: Inicio de trayecto, Actualización de estado y fin de trayecto. El flujo de los eventos es el siguiente:
Flujo de eventos del viaje
Los eventos son recibidos por el primer agente (Agente de traducción). Este agente enriquece los eventos recibidos (Que solamente incluyen la posición GPS del vehículo), con el correspondiente segmento de carretera, así como el estado de circulación y meteorológico del mismo.
Enriquecimiento datos tramo carretera
Los eventos de actualización son tratados por el agente de vehículo, el cual va detectando los cambios de segmento de carretera para acumular todos los sucesos relevantes que hayan pasado, así como el momento de llegada y salida del mismo.
Una vez recibido el evento de fin de viaje, se envía el evento de Viaje realizado, el cual se compone de un conjunto de acumulaciones sobre segmentos que se han realizado, y es procesado por parte del agente de viaje, que genera una nota dependiendo del tipo de vía, su longitud y las diferentes incidencias que se hayan registrado.
A continuación se puede visualizar una de las reglas implementadas en DSI dentro del agente de viaje que define a esta funcionalidad:
Regla de cálculo de Scoring
La segunda funcionalidad incluida dentro del agente de viaje es la correlación entre viajes de diferentes clientes. Hemos incluido dos tipos diferentes de correlación, una para poner en contacto dos clientes distintos y otra para poner en contacto un grupo de clientes.
Correlación 1a1
Estos eventos son tratados por parte del Agente de Viaje, asociado al código postal.
Atención inmediata a una Incidencia durante la conducción
Dentro de la demo SDM, cuando el cliente sufre un percance en la carretera, puede realizar una petición automática a la central, la cual se encargará de contactar con los servicios de reparaciones y emergencias de una manera automática.
El flujo de procesado implementado en DSI es el siguiente:
Como se puede apreciar, el flujo es inicializado por la petición de ayuda por parte del cliente. Según se recibe esta petición, se establece un scheduling en el agente mediante la siguiente regla:
Regla de recepción de petición de ayuda
De acuerdo a esta regla, si no se ha recibido un evento de anulación de petición de ayuda por parte del cliente en un plazo de 3 minutos, se lanzará el resto de la cadena de procesado, donde el evento de ayuda enriquecido con el código postal será procesado por parte del Agente de Viaje (en esta aspecto, el agente es un simple proxy que acumula en este caso los diferentes talleres del código postal), quien, tras comprobar cuál es el taller más cercano, generará la petición de reparación a dicho taller, el cual la enviará a la grúa más cercana.
Por otro lado, se envía una petición al Help Desk para que realice una llamada de seguimiento al cliente.
Si se recibe el evento de anulación de petición de ayuda en un plazo anterior a 3 minutos después de la petición de ayuda, todo este flujo de procesado no es ejecutado.
Publicidad Geoespacial
La publicidad geoespacial consiste en el análisis del viaje realizado por el cliente. Dentro de este análisis, podemos distinguir dos flujos distintos: flujo de análisis a posteriori y flujo de análisis en tiempo real.
Flujo de oferta comercial en viaje finalizado
El flujo de análisis a posteriori se basa en la recepción del evento de viaje finalizado. Como ejemplo de funcionalidad implementada dentro de nuestra demo, tenemos la siguiente regla:
Regla de análisis comercial
Como podemos ver en esta regla, cuando el Scoring de su viaje no supere un cierto límite impuesto por la oferta comercial, se le enviarán las ofertas comerciales de los negocios que estén localizados en la zona de la posición del fin del viaje.
El segundo flujo de análisis en la funcionalidad de publicidad geoespacial es el análisis en tiempo real de las actualizaciones recibidas desde el vehículo.
Regla de análisis comercial tiempo real
Esta regla busca los vehículos que hayan pasado los últimos 20 minutos en tramos que sufran de retenciones y cuya velocidad media sea inferior a 30 kilómetros/hora. Si es así, se enviarán las ofertas comerciales de negocios que estén localizados a menos de una distancia dada.
Estas notificaciones serían mostradas al cliente una vez que el viaje finalice, aplicando un filtro para mostrar solamente aquellas que estén a una distancia dada de su posición final.
Acciones Predictivas
Dentro de la demo SDM, y en el contexto de acciones predictivas, nos hemos centrado en las acciones predictivas relacionadas con las reparaciones de vehículo.
Regla de acumulación de distancia
Para esta demo hemos tratado el mantenimiento predictivo de los neumáticos. La lógica de este proceso consiste en acumular la distancia recorrida por el vehículo desde su último cambio de neumáticos (este cálculo podría ser más fidedigno si fuese ampliado con información del estado de la vía y de la temperatura/humedad ambiente). Cuando vemos que la distancia recorrida llega a un límite dado, se envía una notificación al usuario para indicarle que debería revisar sus neumáticos.
Flujo acción preventiva reparación vehículo
Esta funcionalidad podría ser aumentada ampliando la aplicación móvil con un accesorio OBD-II, el cual permitiría enviar la telemetría de la ECU. De este modo podríamos tener una imagen fidedigna del uso que se le está dando al vehículo y nos permitiría extender las acciones predictivas de reparación a gran parte de los subsistemas (motor, frenos, filtros de aire) con una precisión mucho mayor.
Forense
Una de las funcionalidades más relevantes del Smart Driving Monitor es la capacidad que provee para conocer los hechos ocurridos durante un viaje realizado. De acuerdo a su diseño, los datos obtenidos del entorno que son enriquecidos para producir información de soporte para otras funcionalidades, son registrados en un sistema de almacenamiento masivo de datos para su posterior explotación.
Es en esta funcionalidad donde vemos la capacidad de expansión e integración del SDM con otras tecnologías, por ejemplo, del tipo Big Data. Los datos generados a partir del viaje de un conductor pueden ser extensos ya que éstos dependen de la duración del viaje y de los hechos relevantes que se produzcan, con lo que, si esto lo multiplicamos por “N” número de usuarios los datos se incrementarían en una medida que la mejor forma de explotar sería a partir de una herramienta Big Data.
En nuestra demo hemos utilizado Kibana/ElasticSearch como la herramienta para explotar los históricos, en la que básicamente mediante la ejecución de consultas con sus respectivos criterios obtenemos la información deseada. Por ejemplo, si deseásemos conocer el número de veces en la que vehículos pasaron por un punto específico en un espacio de tiempo determinado, obtendríamos una gráfica como la siguiente:
De igual manera podríamos visualizar los puntos en los que hay una mayor circulación de coches en un espacio de tiempo definido. Esta funcionalidad si bien puede ser visualizada en tiempo real, cuando nos basamos en datos históricos se obtiene una visualización más rica.
Datos de acumulación zona
Como comentamos anteriormente, la integración con otras herramientas Big Data es posible. Es por ello que en la siguiente versión de esta demo y artículo contaremos por ejemplo, con el almacenamiento de los datos en Hadoop y su explotación utilizando Apache Spark, Impala u otras herramientas de los ecosistemas Big Data.
Haber realizado el desarrollo de esta demo con el uso de la herramienta de IBM Decisión Server Insight ha sido una experiencia bastante interesante. Hemos hecho uso de la flexibilidad que proporciona en la ampliación del vocabulario mediante un modelo BOM el cual, a su vez, se apoya sobre módulos OSGi (OSGi es el paradigma sobre el que se ejecuta DSI).
