Posibles Fallas o Causas de error

 Perdida de los datos descargados dentro del datafono debido a perdida de alimentación, reinicio inesperado o falla de comunicación.

 Recepción errónea de la información.

 Envío inadecuado de la información por parte del servidor.

 Exceder la cantidad de datos que se pueden enviar a la impresora térmica.  Interrupción de procesos por duración de la batería.

 Exceder los campos de respuesta en las consultas y los reportes.  Validación de ventas offline como total de ventas en el cierre.  Validación en la generación de reversos.

 Error en la generación del código de venta del tiquete offline.

5.1.1 Perdida de los datos descargados

5.1.1.1 Pérdida de Alimentación

Los datafonos poseen dos tipos de alimentación dependiendo su uso, si es un dispositivo móvil su fuente de alimentación principal es una batería de litio, por el contrario si es un dispositivo de escritorio su alimentación es una fuente de poder externa.

Las baterías de litio se pueden agotar en cualquier momento siempre y cuando el datafono se encuentre en operación. La fuente de poder está sujeta a desconexión por errores humanos o fallas en la red de energía eléctrica.

5.1.1.2 Reinicio Inesperado

Los sistemas de comunicaciones poseen estándares y protocolos definidos; sin embargo, existe un concepto llamado programación defensiva el cual tiene como objetivo garantizar el comportamiento de todo elemento de una aplicación ante cualquier situación por incorrecta o imprevisible que esta pueda parecer.

95 El sistema desarrollado tiene un control de excepciones definido el cual cumple con la función de prevenir procesamiento erróneo de información y de esta manera hacer que el datafono se comporte de una manera predecible pese a entradas y acciones inesperadas.

5.1.1.3 Falla de Comunicación

La red comunicación está sujeta disponibilidad del servicio y fallas de los equipos físicos, esto provoca una interrupción del sistema que puede ser permanente o temporal.

5.1.2 Recepción errónea de la información.

La conexión entre dos dispositivos está expuesta a factores externos, ya que en la variedad de medios ocurren diversos fenómenos que dificultan la adecuada transmisión. Se denomina error a la alteración del mensaje recibido con respecto al mensaje transmitido.

Debido a algunos defectos en los medios de transmisión, pueden producirse errores en la información transmitida. La medición de este error se realiza mediante la tasa de error y se expresa mediante la relación entre el número de bits erróneos recibidos y el número total transmitido. Los errores tienden a agruparse en ráfagas, en vez de ocurrir de manera aislada, este aspecto es una ventaja ya que facilita la detección de los errores, de esta manera, afecta a un subconjunto de la información transmitida y es posible reconstruir este subconjunto a partir del resto.

Al añadir unos bits a los paquetes transmitidos, de forma que identifique los errores cuando se producen, es la manera como se pretende recibir la información con la menor cantidad de errores, así poder ser corregida o simplemente detectada. El modo de obtener la redundancia determina el código de protección frente a errores, hay códigos capaces de corregir n errores independientes de la posición o solamente errores agrupados en un subconjunto de bits.

Para el sistema desarrollado se implementa el método de comprobación de redundancia cíclica (CRC) y de retrasmisión de paquetes.

La verificación de información a través del CRC proporciona la posibilidad de validar cada uno de los paquetes recibidos y descartar paquetes que sufren alteraciones en su trasmisión.

Del desarrollo apropiado de la verificación del dato CRC surge la necesidad de implementar el método que haga posible la retrasmisión de un paquete con fallas. Este método de retrasmisión segmenta la información en una cantidad finita de paquetes n, este valor permite solicitar el paquete exacto que haya sufrido el error durante su trasmisión, con esto se asegura que la información a almacenar en el dispositivo móvil es la esperada sin lugar a errores durante su verificación.

96 El dispositivo transmisor calcula el CRC añadiéndole al dato el número correcto de ceros. Los datos se procesan utilizando matemática binaria. En el siguiente diagrama de flujo se muestra el proceso de cálculo del CRC.

ILUSTRACIÓN 48: CALCULO DEL CRC

5.1.3 Envío inadecuado de la información por parte del servidor

Al existir un envío inadecuado de la información por parte del servidor pueden existir un número elevado de excepciones no controladas por parte del datafono, sin embargo gracias al diseño del protocolo de mensajería, es posible realizar mapeos previos de los campos a utilizar en cada transacción. La posibilidad de existir desbordes de memoria es latente, para ello se ha utilizado un método de errores controlados que permite por medio programación estructurada validar el tamaño de la porción de memoria que recibe y la longitud de los datos a recibir. Se realiza una comparación entre estos 2 datos y se procede a seguir el proceso correspondiente dependiendo si es exitosa o no la validación.

97

5.1.4 Exceder la cantidad de datos que se pueden enviar a la impresora térmica

Entre las pruebas que se realizaron se observó que la cantidad de datos enviados a la impresora puede ser muy alto, generalmente cuando se trata de reportes o apuestas con un número considerable de jugadas. Este caso fue evidente al realizar un reporte de lista de números en rangos de fechas distantes, para ello se han canalizado por código los procesos que generalmente podrían generar este tipo de inconveniente. En este sentido se hace un conteo de los datos y se validan para enviar a imprimir lo que se tiene primero en el buffer y volver a llenar con nuevos datos. Para evitar este inconveniente se pensó en la posibilidad de enviar a imprimir de inmediato se recibía un carácter a imprimir, pero este proceso agota la batería porque se debe estar abriendo y cerrando el periférico de salida (Impresora), además de sobrecalentamiento del mismo, la impresora tiene un máximo de 1kB por impresión.

5.1.5 Interrupción de procesos por duración de la batería

En cuanto a este tipo de error, lo primero que se debe hacer es identificar los procesos más importantes que realizan el sistema y observar que sucede si se cortan de manera súbita. Es claro que los procesos más importantes son el envío y la recepción en una transacción además de la impresión de tiquetes.

En el caso de envío y recepción el POS envía un reverso de la venta si esta no es percibida y procesada, en cuanto a la impresión de tiquetes, si se corta en la mitad de una impresión, es normal que la venta no se almacene en memoria, o si el papel se acaba, el tiquete es impreso por completo nuevamente. En la descarga remota el datafono es capaz de recuperar el paquete de descarga donde estaba y comenzar la retransmisión con el servidor.

5.1.6 Exceder los campos de respuesta en las consultas y los reportes

Es normal que por las cantidades de datos los campos que hacen la recepción de este tipo de transacciones puedan ser desbordados, sobre todo si en ocasiones la cantidad de datos a recibir es variable tal cual lo indica el protocolo desarrollado. Este tipo de sistema embebido no tiene la facilidad de generar porciones de memoria adicional si viene información extra, para ello con ayuda nuevamente de una programación defensiva, se ha utilizado la reserva dinámica de memoria que posee el SDK para tratar esta situación de la manera más eficiente, lo que evita interrupciones en el funcionamiento del software y mapeo ineficiente de la memoria en el dispositivo, es decir, desperdicio de memoria.

5.1.7 Validación de ventas offline como total de ventas en el cierre

Al realizar un proceso de cierre es conveniente tener en cuenta que existan ventas offline para empalmar con el inventario que tiene el receptor de transacciones. Ocasionalmente se observó que se hacían cierres y se sincronizaban las ventas, sin embargo habían ventas que nunca lograban realizar la sincronización, se observó que en algunas ocasiones al existir una conexión intermitente y lenta la transacción era reversada por timeout, pero en el POS el reverso no era marcado con el mismo

98 consecutivo de salida de venta en el POS. Para esto se hizo revisión paso a paso del código con ayuda de la herramienta de depuración que posee el SDK del POS, observando los valores que tomaba cada espacio de memoria en este proceso y se corrigió puntualmente.

5.1.8 Validación en la generación de reversos y la sincronización

Los reversos según el entorno bancario deben ser ocasionados siempre que el tipo de transacción conlleve al descuento o al abono de dineros a cuentas bancarias, en este caso la cuenta bancaria es el servidor de Pérez Abreu, el cual valida cada una de las ventas que hacen las terminales y a su vez las contrasta directamente sobre el sistema de cada lotería. Recordemos que tanto las recargas, como la venta de apuestas, el batch y la sincronización tienen una forma similar en el envío de transacciones. Las transacciones anteriormente citadas conllevan un reverso sino se percibe respuesta por parte del servidor, sin embargo por la calidad de la red los reversos se convirtieron en el pan de cada día en municipios alejados de cabeceras urbanas. Para controlar este tipo de inconvenientes y evitar que el datafono se quede esperando la respuesta del servidor, se ha optado porque el reverso solo se envíe siempre y cuando exista una ausencia de las respuestas para la venta de las apuestas, en el caso de las recargas se habla de un reverso Host to Host, el cual es generado por el servidor de Pérez Abreu y hace que el proceso del POS no tome vital importancia en este proceso.

Además a lo anterior se suma la cantidad de reversos que se podrían presentar sincronizando un lote de apuestas offline, por ello también se implementó una transacción que hace consulta de sincronización, y contrasta cada una de las ventas que se enviaron para sincronización en una sola transacción sin esperar reverso de un posible timeout al sincronizar.

Los lotes de apuestas se sincronizan venta por venta sin esperar respuesta, solo al final se hace la transacción de consulta que es de envío y recepción, y se marca en el lote ventas si su estado cambió en el servidor, evitando a toda costa que las máquinas se queden inhibidas en un proceso de reverso cuando la conexión es de baja calidad.

Por último se ha optado porque se operen las terminales con APN privado para evitar que las transacciones viajen por un canal de comunicación público y se registre conexión lenta por la demanda del mismo, lo que disminuye aún más el porcentaje de reversos presentados en las ventas de hechas desde el POS.

5.1.9 Error en la generación del código de venta del tiquete offline

Erróneamente se implementó como primera medida marcar los tiquetes offline solo con la fecha completa de venta, sin embargo se debe tener en cuenta que las ventas son simultaneas y pueden existir errores de seguridad al jugar el tiquete, ya que se identifica por medio del código de barras su autenticidad.

99 Para generar el código de barras se utiliza un código de seguridad que viaja en el detalle de la venta, este código se genera con un algoritmo llamado "generarNumeroTicket" que realiza una serie de pasos matemáticos que utiliza los siguientes datos a manera de ejemplo:

Serial de la máquina. 3C39714 Fecha de venta: 20150805 Hora de venta: 181615

Dando como resultado de su paso un 5958835437.

Al utilizar la fecha de la venta con la hora, la probabilidad de encontrar códigos similares es mínima, incluyendo por supuesto el serial de la máquina. En este caso, este algoritmo también es validado y contrasta con la lógica del servidor para verificar la autenticidad de un tiquete offline.