Biblioteca de software para terminal de...

UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Biblioteca de software para terminal deautogestión

Autor:Ing. Diego Fernández

Director:Dr. Ing. Pablo Martin Gomez (FIUBA)

Jurados:Esp. Ing. Pedro Martos (UBA)Ing. Federico Zacchigna (UBA)

Ing. Octavio Alpago (UBA)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entre juliode 2016 y diciembre de 2016.

III

Resumen

En la presente memoria se aborda el diseño y desarrollo de una biblioteca demanejadores de dispositivos (drivers) para la terminal de autogestión fabricadapor la empresa Debmedia. Dicha terminal de autogestión se utiliza para facilitar

y automatizar tareas de atención al público, y según la aplicación puedecontener un lector de tarjetas magnéticas, lector de billetes, sensor de huellas

dactilares y/o escáner de cheques.

El proyecto contempla la selección de tecnologías de software a utilizar, eldiseño de la arquitectura en capas, desarrollo de drivers de cada periférico y el

desarrollo de interfaces para utilizarlos en otros lenguajes. A lo largo delproyecto se aplicaron conceptos de gestión de proyectos e ingeniería de

software. En este documento se incluye una descripción detallada de cada tarearealizada, ensayos y resultados, y las conclusiones del proyecto.

V

Agradecimientos

En estas líneas quiero agradecer a todas las personas que estuvieron cerca mío yayudaron a que este proyecto se realice.

A mis padres y hermanos porque a pesar de estar a la distancia, siempre estánpara aconsejarme, animarme y apoyarme.

A Sofía, por su compañía, paciencia y apoyo incondicional en todo lo que empre-da a pesar de que signifique menos tiempo juntos.

A la empresa Debmedia por permitirme realizar este proyecto y en especial alIng. Ezequiel Espósito por haber confiado en mí y por darme una mano en cadamomento que la necesité. A todos mis compañeros de trabajo por acompañarmedía a día.

A los profesores de la carrera de Especialización en Sistemas Embebidos que meacompañaron en esta formación profesional. Al director Dr. Ing. Ariel Lutenbergpor su dedicación, consejos y guía durante la realización del proyecto.

A todos ellos, muchas gracias.

VII

Índice general

Resumen III

1. Introducción General 11.1. Aplicaciones de autogestión . . . . . . . . . . . . . . . . . . . . . . . 11.2. Motivación y objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Alcance y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Introducción Específica 72.1. Terminal de autogestión . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Periféricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1. Lector de tarjetas magnéticas . . . . . . . . . . . . . . . . . . 72.2.2. Lector de billetes . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3. Sensor de huella dactilar . . . . . . . . . . . . . . . . . . . . . 102.2.4. Escáner de cheques . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3. Diseño e Implementación 153.1. Selección de tecnologías . . . . . . . . . . . . . . . . . . . . . . . . . 153.2. Arquitectura del software . . . . . . . . . . . . . . . . . . . . . . . . 173.3. Capa de drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.1. Lector de tarjetas magnéticas . . . . . . . . . . . . . . . . . . 203.3.2. Lector de billetes . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.3. Sensor de huella dactilar . . . . . . . . . . . . . . . . . . . . . 233.3.4. Escáner de cheques . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4. Capa de interfaz Javascript . . . . . . . . . . . . . . . . . . . . . . . . 263.4.1. Lector de tarjetas magnéticas . . . . . . . . . . . . . . . . . . 273.4.2. Lector de billetes . . . . . . . . . . . . . . . . . . . . . . . . . 293.4.3. Sensor de huella dactilar . . . . . . . . . . . . . . . . . . . . . 303.4.4. Escáner de cheques . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5. Compilación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4. Ensayos y Resultados 354.1. Lector de tarjetas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2. Lector de billetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3. Sensor de huela dactilar . . . . . . . . . . . . . . . . . . . . . . . . . 404.4. Escaner de cheques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5. Conclusiones 495.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Bibliografía 51

IX

Índice de figuras

1.1. Arquitectura general del hardware de un kiosco interactivo. . . . . 11.2. Arquitectura general de un sistema de autogestión. . . . . . . . . . 21.3. Ejemplo de una aplicación de autogestión. . . . . . . . . . . . . . . . 31.4. Kiosco interactivo de la empresa Slabb, líder internacional. . . . . . 41.5. Kioscos interactivos de la empresa Tallion utilizados en la Ciudad

de Buenos Aires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1. Lector de tarjetas magnéticas Magtek MSR-100. . . . . . . . . . . . . 82.2. Lector de billetes JCM iVizion SS/SU. . . . . . . . . . . . . . . . . . 92.3. Sensor de huella dactilar U.are.U 5100. . . . . . . . . . . . . . . . . . 112.4. Escáner de cheques Puloon PCSU-100. . . . . . . . . . . . . . . . . . 112.5. Transferencia masiva (bulk) entre controlador y dispositivo. . . . . 13

3.1. Arquitectura en capas de software desarrollada. . . . . . . . . . . . 183.2. Capa de drivers desarrollada. . . . . . . . . . . . . . . . . . . . . . . 193.3. Capa de interfaz Javascript desarrollada. . . . . . . . . . . . . . . . 263.4. Salida de consola de una tarea de compilación iniciada con la he-

rramienta GYP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1. Salida de consola de aplicación de test del driver del lector de tarjetas. 364.2. Salida de consola de aplicación de test de la librería del lector de

tarjetas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3. Mensaje de error de la librería del lector de tarjetas. . . . . . . . . . 374.4. Salida de consola de aplicación de test de la librería del validador

de billetes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.5. Salida de consola de aplicación de test de la interfaz del validador

de billetes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.6. Leds del dispositivo iVizion indicando que se encuentra habilitado

para la captura de billetes. . . . . . . . . . . . . . . . . . . . . . . . . 424.7. Funcionamiento de los leds en las pruebas del sensor de huella

dactilar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.8. Datos de imagenes de huellas capturadas con el sensor U.are.U 5100. 444.9. Mensajes de capturas erroneas del lector de huella dactilar. . . . . . 444.10. Funcionamiento de los leds en las pruebas del lector de cheques. . 464.11. Salida de consola de aplicación de test de la interfaz del lector de

cheques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

XI

Índice de Tablas

2.1. Especificaciones de kioscos . . . . . . . . . . . . . . . . . . . . . . . 82.2. Estructura de datos del protocolo Id-003 . . . . . . . . . . . . . . . . 102.3. Especificaciones del lector de cheques PCSU-100 . . . . . . . . . . . 122.4. Estructura de datos de transferencia del lector de cheques . . . . . . 122.5. Estructura de datos de recepción del lector de cheques . . . . . . . 12

3.1. Comparación entre tecnologías disponibles . . . . . . . . . . . . . . 163.2. Página de uso del lector Magtek . . . . . . . . . . . . . . . . . . . . . 203.3. Estructura de datos del lector Magtek . . . . . . . . . . . . . . . . . 213.4. Tipos de mensajes del driver del lector de billetes . . . . . . . . . . 233.5. Tipos de mensajes del driver del sensor de huella dactilar . . . . . . 243.6. Tipos de mensajes del driver del escáner de cheques . . . . . . . . . 253.7. Eventos implementados en la interfaz del lector de billetes . . . . . 303.8. Estados implementados en la interfaz del lector de billetes . . . . . 313.9. Eventos implementados en la interfaz del sensor de huella dactilar 313.10. Eventos implementados en la interfaz del escáner de cheques . . . 323.11. Estados implementados en la interfaz del escáner de cheques . . . . 33

1

Capítulo 1

Introducción General

En esta sección se presenta una descripción de las aplicaciones de autogestión,casos de uso y soluciones disponibles en el mercado. Se presenta la motivaciónque da origen a este proyecto asi como sus objetivos, alcances y limitaciones.

1.1. Aplicaciones de autogestión

Las aplicaciones de autogestión se basan en la utilización de un sistema embebidopara facilitar y automatizar tareas de atención al publico, en general, en centroscomerciales, bancos, hospitales y centros médicos.

El sistema embebido utilizado en este tipo de aplicaciones se denomina kioscointeractivo o terminal de autoservicio y como se ve en la figura 1.1, está integradopor una computadora embebida (Single Board Computer o SBC) a la que se leconectan los periféricos que interactúan con el usuario: pantalla táctil, impresora,micrófono y teclado, entre otros. Cuentan además con una aplicación de softwareque provee información y servicios de una manera clara y sencilla de utilizar.

FIGURA 1.1: Arquitectura general del hardware de un kiosco in-teractivo.

2 Capítulo 1. Introducción General

Actualmente estas soluciones se han sofisticado de manera creciente agregandocada vez más periféricos, aumentando la interacción con el usuario y permitiendoa las empresas promocionar favorablemente su producto, servicio o imagen.

En algunas aplicaciones se las utiliza conjuntamente con un sistema integral deatención al publico, como se ve en la figura 1.2. En este caso particular el kioscointeractivo se integra a un sistema de turnos. Con este esquema la empresa puede,mediante sensores biométricos por ejemplo, detectar el cliente que ingresa a susistema de turnos y darle prioridad en el caso que corresponda.

FIGURA 1.2: Arquitectura general de un sistema de autogestión.

Un ejemplo de una aplicación de autogestión puede verse en la figura 1.3.

En las figuras 1.5 y 1.4 se pueden ver dos soluciones comerciales que existen enel mercado nacional e internacional respectivamente.

Estas soluciones se ofrecen dedicadas para un uso particular y con un softwaredesarrollado a medida por la empresa que los fabrica. En general se ofrecen comoun producto cerrado y “plug and play”para el cliente.

1.2. Motivación y objetivo

El uso de kioscos interactivos en el entorno local está ganando popularidad y lasempresas están adoptando la estrategia de utilizarlos para mejorar su atención alpúblico. Los kioscos le permiten agilizar y optimizar procesos que normalmen-te requieren de la interacción humana. Por otro lado también proporcionan unaimagen moderna y sofisticada en el establecimiento.

Este proyecto surge de la necesidad de la empresa Debmedia de expandir su car-tera de productos añadiendo el producto “debTouch”. La idea detrás de este pro-ducto es la de ofrecer una solución integral para el desarrollo de aplicaciones parakioscos interactivos, realizadas a medida de las necesidades del cliente y que per-mitan el desarrollo fácil y rápido. Se busca que el cliente que quiera desarrollar

1.3. Alcance y limitaciones 3

FIGURA 1.3: Ejemplo de una aplicación de autogestión.

aplicaciones sobre una terminal pueda realizarlo fácilmente sin necesidad de co-nocer el hardware, es decir, abstraerse del mismo y poder usar una biblioteca desoftware que le facilite la integración de su aplicación con el equipo.

Tal como se comentó en la sección anterior los fabricantes de este tipo de solu-ciones ofrecen un producto cerrado y con el software desarrollado a medida delcliente. Esto no genera flexibilidad en el cliente ya que si quiere añadir funcio-nalidad nueva o modificar el software no lo puede hacer por su cuenta. Por otrolado algunos fabricantes ofrecen una interfaz en lenguaje C++ o Java para que secomuniquen con el hardware directamente, el problema de esto es que el clientedebe conocer el funcionamiento de cada periférico para poder integrarse, lo querepresenta más tiempo y mas especialización en el desarrollo.

La solución propuesta por este trabajo permite al cliente no tener que conocer elfuncionamiento y los protocolos de comunicación con cada periférico, sino quesolo necesita integrarse en alto nivel a la biblioteca de software.

1.3. Alcance y limitaciones

El proyecto realizado contempló:

Selección de la tecnología de software a utilizar.

Diseño de la arquitectura a utilizar dentro de una aplicación de autogestión.

Desarrollo de drivers para lector de tarjetas magnéticas, lector de billetes,sensor de huella digital y escáner de cheques.

4 Capítulo 1. Introducción General

FIGURA 1.4: Kiosco interactivo de la empresa Slabb, líder interna-cional.

Diseño de una interfaz de software para utilizar las librerías en una aplica-ción web (lenguaje Javascript).

El proyecto no contempló:

El desarrollo del hardware de la terminal de autogestión ni del de sus peri-féricos.

El desarrollo de una aplicación embebida sobre la plataforma.

7

Capítulo 2

Introducción Específica

En esta sección se presenta un detalle de la terminal de autogestión a utilizar enel proyecto. Se detalla cada periférico utilizado, con sus características y funcio-nalidades disponibles.

2.1. Terminal de autogestión

Tal como se describió en el capítulo 1, la terminal de autogestión es un sistemaembebido integrado por una computadora embebida (Single Board Computer oSBC) a la que se le conectan los periféricos que interactúan con el usuario. Si bienel equipo se desarrolla para que tenga una sola aplicación, la computadora em-bebida debe tener los recursos suficientes para reproducir contenido multimediacon fluidez, por lo que en general se utilizan procesadores y sistemas operativosde uso general y de alta capacidad.

En la tabla 2.1 se pueden ver las especificaciones técnicas de dos terminales desa-rrolladas por la empresa Debmedia. En cuanto a recursos de procesamiento y al-macenamiento son muy similares y permiten comprobar lo dicho anteriormente,si bien es un hardware dedicado a una aplicación específica no se utilizan micro-controladores sino procesadores de uso general. Lo mismo ocurre con el sistemaoperativo que utilizan.

Para este proyecto no se utilizó una terminal en particular, ya que la mayoría deestas soluciones de hardware se desarrollan siguiendo las necesidades del cliente,agregando los periféricos y módulos que se ajusten a la aplicación.

2.2. Periféricos

2.2.1. Lector de tarjetas magnéticas

El lector de tarjetas utilizado en el proyecto es el modelo MSR-100 de la marcaMagtek, empresa dedicada a la fabricación de tecnología de pagos e identificaciónelectrónica. En particular el lector MSR-100, que se muestra en la figura 2.2, es unlector de tarjetas de banda magnética que cuenta con un solo cabezal de lecturarespetando los estándares ISO y conformando las especificaciones de dispositivosde interfaz humana versión 1.1 (USB HID Class 1.1). El lector es compatible concualquier dispositivo que cuente con una interfaz USB Host.

8 Capítulo 2. Introducción Específica

TABLA 2.1: Especificaciones técnicas de algunos modelos de kios-cos Debmedia.

Característica DTKS-ATM-10/20 DTKS-TK

Medidas 50x50x155 cm 30x50x150 cmPeso 90 Kgs 40 KgsConectividad Ethernet / WiFi EthernetMonitor IR Touchscreen 19“ IR Touchscreen 19“Sistema Operativo Windows 7 Ubuntu 14LTSDisco Rígido 500 Gb 500 GbRAM 4 Gb 4 GbProcesador Intel Core I3 Quad Core 1600 Mhz x64Banda magnética Si SiLector biométrico - SiValidador de billetes Si -Gabinete Acero SAE 1010 6mm Acero SAE 1010 6mmImpresora Térmica Térmica

FIGURA 2.1: Lector de tarjetas magnéticas Magtek MSR-100.

Algunas de las características del lector son:

Alimentación por interfaz USB (no requiere fuente de alimentación exter-na).

Lectura bidireccional.

Lectura de datos codificados con estándares ANSI/ISO/AAMVA.

Lectura de hasta 3 pistas de datos.

Led indicador de lectura.

Compatible con especificación USB HID v1.1

Numero de serie USB programable.

Memoria de configuración no volátil.

Capacidad de funcionar como emulador de teclado.

2.2. Periféricos 9

Su funcionamiento se basa en la lectura de una tarjeta cuando se la desliza porla ranura del lector de forma que la banda magnética se encuentre mirando ha-cia abajo y hacia la cara del indicador led. El indicador led funciona de formaautomática y avisa al operador cuando se realiza la lectura.

En cuanto a la comunicación con el dispositivo maestro el lector envía los datosen forma de reportes siguiendo el estándar HID. Los mismos se pueden ver en elmanual técnico del dispositivo [14] y se detallan en el capítulo 3 ya que son losque deben ser obtenidos por el driver del dispositivo.

2.2.2. Lector de billetes

Un lector de billetes es un dispositivo que valida si un billete es genuino y deter-mina su valor para luego almacenarlo. El utilizado en las terminales Debmediaes el iVizion SS/SU fabricado por la empresa JCM, mostrado en la figura 2.2.

FIGURA 2.2: Lector de billetes JCM iVizion SS/SU.

En funcionamiento normal, el lector realiza un proceso de validación que involu-cra la examinación del billete que se insertó en el dispositivo, y mediante variaspruebas, determina si el billete es falso. Si el billete es aceptado se lo retiene en uncontenedor, y si es rechazado el dispositivo lo devuelve. Dado que los parámetrosson diferentes para cada tipo de billete, estos detectores están programados paracada elemento que se van a aceptar.

La comunicación con el dispositivo se realiza mediante RS-232 utilizando el pro-tocolo Id-003 [4]. Este protocolo es una interfaz bidireccional, específico para estetipo de dispositivos, y permite a un “controlador” conocer el estado y controlarlas acciones del “validador”. Funciona utilizando el principio de polling, es decir


que se deben realizar operaciones de consulta constante para crear una actividadsincrónica sin el uso de interrupciones.

El formato de mensaje Id-003 se muestra en la tabla 2.2.

TABLA 2.2: Estructura de datos del protocolo Id-003.

Nombre Longitud Descripción

SYNC 1 Byte de inicio de mensajeLNG 1 Longitud del mensajeCMD 1 Comando o instrucciónDATA 0 - 250 Dato a enviar según el tipo de comandoCRC 2 CRC Kermit

El equipo cuenta además con un led indicador en el panel frontal que puede sercontrolado por el usuario. El mismo puede ser encendido o apagado modificandoel estado del pin RTS (Request to Send) del puerto serie.

2.2.3. Sensor de huella dactilar

Una huella dactilar es la impresión visible o moldeada que produce el contactode las crestas papilares de un dedo de la mano (generalmente se usan el dedopulgar o el dedo índice) sobre una superficie. Es una característica individual quese utiliza como medio de identificación de las personas

Los dispositivos sensores de huella dactilar, usualmente llamados sensores bio-métricos, realizan dos tareas principales: obtener una imagen de una huella dac-tilar y generar a partir de ella un patrón de valles y crestas. Este patrón es el quese usa para comparar con capturas hechas previamente y realizar la validaciónde una persona.

El sensor utilizado es el proyecto es el U.are.U 5100 de la marca DigitalPersonamostrado en la figura 2.3. Se trata de un dispositivo que realiza la captura dela huella dactilar utilizando un método óptico y su uso es dedicado a sistemasembebidos.

El método óptico del U.are.U 5100 funciona con un dispositivo CCD (ChargedCoupled Device), como el usado en las cámaras digitales, que tienen un arreglode diodos sensible a la luz que generan una señal eléctrica en respuesta a fotonesde luz. Cada diodo graba un pixel, un pequeño punto que representa la luz quele es reflejada. Colectivamente, la luz y perfiles oscuros forman una imagen dela huella leída. El proceso de lectura comienza cuando se pone un dedo sobre laventana del lector, el cual tiene su propia fuente de iluminación, típicamente unarreglo de LEDs, para iluminar las crestas de la huella digital. El CCD genera,de hecho, una imagen invertida del dedo, con áreas más oscuras que representanmás luz reflejada (las crestas del dedo) y áreas más claras que representan menosluz reflejada (los valles entre las crestas).

La comunicación con el sensor se realiza a través de una interfaz USB 2.0 [11].

2.2. Periféricos 11

FIGURA 2.3: Sensor de huella dactilar U.are.U 5100.

2.2.4. Escáner de cheques

Un escáner de cheques, similar al lector de billetes, es un dispositivo que validasi un cheque es genuino para luego almacenarlo. El utilizado en las terminalesDebmedia es el PCSU-100 fabricado por la empresa Puloon, mostrado en la figura2.4.

FIGURA 2.4: Escáner de cheques Puloon PCSU-100.

El dispositivo cuenta con un módulo de reconocimiento de caracteres de tintamagnética (MIRC), utilizados en los cheques y otros documentos bancarios, y unmódulo de impresión de puntos para realizar marcas de cheques validados.

Las especificaciones técnicas pueden encontrarse en el manual del dispositivo[10]. Las características principales del lector se detallan en la tabla 2.3.

Como puede verse en la tabla 2.3 la comunicación con el lector es a través de unainterfaz USB. Las transferencias de mensajes por protocolo USB pueden ser de 4tipos: transferencias de control (control transfers), transferencias de interrupción


TABLA 2.3: Especificaciones técnicas del lector de cheques PCSU-100.

Característica Detalle

Rango de escaneo Tamaño A6 o 108mmVelocidad 500mm/sec

MICR E13B y CMC7Interface USB2.0 High SpeedVoltaje DC24V

(interrupt transfers), transferencias sincrónicas (isochronous transfers) y transfe-rencias masivas (bulk transfers). En particular para este dispositivo se usan lastransferencias masivas. Las características de este tipo de transferencia son:

Utilizados para transferir mucha cantidad de datos.

Realiza detección de errores con CRC.

Posee mecanismos de retransmisión de paquetes ante fallos del CRC.

Utiliza todas las porciones de ancho de banda disponible en el bus.

Posee buffer unidireccional.

La estructura de los mensajes por USB utilizados para comunicarse con el lectorse muestran en las tablas 2.4 y 2.5. En la primera se detalla el formato del mensajeque se envía desde el controlador y en la siguiente el formato del mensaje que serecibe del lector.

TABLA 2.4: Estructura de datos de transferencia del lector de che-ques Puloon PSCU-100.


MI 2 Indicador del mensajeLNG 3 Longitud del mensaje en ASCII

DATA 0 - 128 Datos del mensajeSEP 1 Byte de finalización de mensaje (0x0D)

TABLA 2.5: Estructura de datos de recepción del lector de chequesPuloon PSCU-100.


MI 2 Indicador del mensajeLNG 3 Longitud del mensaje en ASCII

ERROR 4 Codigo de errorDATA 0 - 128 Datos del mensaje

DUMMY DATA 0 - 128 Bytes utilizados para completar 128 bytes totalesSEP 1 Byte de finalización de mensaje (0x0D)

El procedimiento de transmisión de mensajes se muestra en la figura 2.5. El con-trolador (host) envía el mensaje al lector (unit) por transferencia masiva (bulk) y

2.3. Requerimientos 13

luego de la operación, el lector responde por medio de otra transferencia masiva,en este caso en modo recepción.

FIGURA 2.5: Transferencia masiva (bulk) entre controlador y dis-positivo.

Esta sección ha sido removida para publicación online

ya que el presente trabajo tiene fines comerciales.

15

Capítulo 3

Diseño e Implementación

En esta sección se presenta en detalle todo el desarrollo realizado. Se describentodas las tecnologías disponibles con sus ventajas y desventajas y la justificaciónde las tecnologías elegidas. Se muestra la arquitectura de software desarrollada,capas de software y la estructura del código. Se explican tanto la estructura decódigo de cada driver e interfaz como sus funcionamientos.

3.1. Selección de tecnologías

El requerimiento principal de proyecto establecía que se realicen dos módulosprincipales de software: el módulo de drivers y el módulo de interfaz.

En el caso de la capa de drivers, la misma debía permitir ser reutilizada paragenerar drivers en varios sistemas operativos. En primera instancia, solo paraWindows y Linux.

Por otra parte, en el caso de la capa de interfaz, si bien en una primer instanciase desarrolló en lenguaje Javascript, lo que se requiere es que en el futuro existandistintos módulos de interfaz, uno por cada lenguaje soportado.

Estos dos requerimientos importantes fueron los que condicionaron la selecciónde tecnologías.

El primer paso consistió en la elección del lenguaje a utilizar en la capa de drivers.El lenguaje C++ es un lenguaje altamente difundido y utilizado, y es el único quepermite crear librerías y APIs para ser usadas en otros lenguajes a través de mé-todos de adaptación (bindings). Por otro lado, en el caso particular del lector dehuella dactilar, el fabricante proporcionó librerías con funciones en C++ con lasfuncionalidades básicas del dispositivo. Por estos motivos se decidió que el mó-dulo de drivers se desarrolle enteramente en lenguaje C++ siguiendo el estándarISO/IEC 2011, lo que permitiría que el módulo de drivers se desarrolle una solavez y sea reutilizado en todos los soportes a los distintos lenguajes.

Como segundo paso se buscaron las tecnologías que permitan ejecutar softwa-re nativo en un entorno web. En general el entorno web funciona dentro de un“sandbox” seguro, sin posibilidad de acceder al hardware ni a aplicaciones exter-nas, pero existen opciones para que un navegador pueda acceder a componentesde externos de forma controlada. Las tecnologías que lo permiten son:

Google Native Client (PNaCl y NaCl).

Mozilla Asm.js.

16 Capítulo 3. Diseño e Implementación

Microsoft ActiveX.

Node C++ Addons.

En la tabla 3.1 se muestra una comparación entre todas las tecnologías disponi-bles.

TABLA 3.1: Comparación entre tecnologías de uso de software na-tivo en C/C++ en entorno web.

Tecnología Ejecuta C/C++ Accede a Hardware SO

Google Native Client Si Si Linux, WindowsMozilla Asm.js Si (traducido) No Linux, WindowsMicrosoft ActiveX Si Si WindowsNode C++ Addons Si Si Linux, Windows

Mirosoft ActiveX [5] fue una opción descartada ya que si bien permite la realiza-ción de módulos que accedan a componentes de hardware, fue desarrollado solopara el navegador Microsoft Internet Explorer por lo que no permite un sopor-te multiplataforma, sumado al hecho que Microsoft no lo incluyó en su nuevonavegador web.

Mozilla Asm.js realiza la compilación de un código en C++ a un código en Javas-cript que puede ser utilizado luego en un entorno web [1]. El problema con estatecnología es que si bien se puede ejecutar un código de C++ en Javascript, estesigue corriendo en el “sandbox” de la aplicación web, es decir no permite accederal hardware. Por este motivo también fue una opción descartada.

El cliente nativo de Google (Google Native Client) permite la utilización de có-digo C y C++ compilado en el navegador Google Chrome de forma segura, in-dependiente del sistema operativo y acceder a ciertos componentes del sistemaoperativo, incluido el hardware [2]. Posee dos formas de funcionamiento:

Cliente Portable (PNaCl): Se corren ejecutables portables (pexe). Un móduloya integrado en el motor del navegador realiza la traducción del pexe a có-digo nativo antes de que sea ejecutado. Puede ser servido desde un servidorweb.

Cliente Nativo (NaCl): Es el sistema más utilizado. Se corren ejecutables queson dependientes de la arquitectura (nexe). Al iniciar, el navegador elije elmódulo nexe que debe cargarse según la arquitectura del cliente.

Un módulo de cliente nativo y un módulo Javascript se comunican mediante elenvíos de mensajes y la ejecución de funciones que manejan dichos mensajes. Estacomunicación es bidireccional.

Otra opción tecnológica se trata de los módulos C/C++ de Node (Node C/C++Addons) [6]. Node es un entorno de ejecución Javascript multiplataforma de có-digo libre en donde se interpreta código de Javascript utilizando el motor V8 deGoogle. Estos “addons” se tratan de objetos referenciados dinamicamente (dynamically-linked shared objects) escritos en C o C++ que pueden ser utilizados en una apli-cación Node. Son utilizados normalmente para hacer interfaces entre librerías enC/C++ y Javascript.

3.2. Arquitectura del software 17

Por el momento el método para implementar “addons” es complicado, ya querequiere conocer ciertos componentes:

V8: Es la librería C++ que utiliza Node para realizar las implementacionesJavascript. V8 provee los mecanismos para creación de objetos, llamar fun-ciones, etc.

libuv: Es la librería en C para eventos recursivos, tareas y todo el compor-tamiento asincrónico de la plataforma. Sirve además como una librería deabstracción POSIX multiplataforma.

Librerías internas: Node expone APIs C/C++ para que cualquier módulopueda utilizarlas.

Se decidió realizar la capa de interfaz utilizando la tecnología de módulos nativosde Node. La elección frente al cliente nativo de Google se realizó teniendo encuenta la actividad en sus repositorios de código. Esto da una medida de cuantoavance y uso esta teniendo.

En el caso del cliente nativo de Google los datos obtenidos del repositorio princi-pal (NaCl-main) muestran que se realizaron 35 commits en los últimos 12 mesesy colaboraron 12 personas [7]. Si se miran los 12 meses anteriores se ve que serealizaron 1578 más commits y participaron 40 personas más. Esto muestra quela actividad en dicha tecnología está en decadencia y cada vez menos personas laestán utilizando.

Por el otro lado, en el repositorio principal de Node, se ve que se realizaron 2860commits de 402 personas [8]. Si se miran los 12 meses anteriores los datos sonmenores, 2458 commits de 271 personas. Estos datos verifican que la tecnologíaNode esta siendo más usada y el número de personas colaboran activamente conel proyecto va en aumento.

3.2. Arquitectura del software

35

Capítulo 4

Ensayos y Resultados

En esta sección se muestran las aplicaciones que se desarrollaron para probar losmódulos de drivers y de interfaz realizados en este proyecto.

49

Capítulo 5

Conclusiones

5.1. Conclusiones generales

En el proyecto realizado se diseñó y desarrolló una biblioteca de manejadores dedispositivos (drivers) para la terminal de autogestión fabricada por la empresaDebmedia.

Se seleccionaron las tecnologías de software a utilizar buscando las que esténmás difundidas en el mercado y permitan agregar nuevas funcionalidades en unfuturo.

Se diseñó la arquitectura del software en capas para poder reutilizar la bibliotecaen otros lenguajes y otras arquitecturas de hardware.

Se desarrolló una capa de drivers y una capa de interfaz en Javascript para cadaperiférico (lector de tarjetas, sensor de huella dactilar, lector de billetes y escánerde cheques) manteniendo los mismos metodos y funcionalidades.

Durante el desarrollo de este proyecto se aplicaron conocimientos adquiridos a lolargo de la Carrera de Especialización en Sistemas Embebidos. Si bien todas lasmaterias aportaron conocimiento útil, se aplicaron conocimientos específicos delas materias:

Ingeniería de Software en Sistemas Embebidos: Se utilizaron técnicas dedesarrollo del software en capas y de abstracción del hardware que permi-tieron reutilizar código y modularizar el desarrollo del proyecto. Se utilizóun método sistemático e iterativo de desarrollo pensando en el ciclo de vidadel software. Se utilizó Git como sistema de control de versiones del soft-ware.

Gestión de Proyectos en Ingeniería. Resultó de gran utilidad elaborar unPlan de Proyecto para organizar el proyecto y poder realizarlo de maneraprofesional y organizada.

Asimismo, durante el desarrollo del trabajo final se adquirieron conocimientos enlas áreas de:

Programación en lenguaje C++ y JavaScript.

Generación de módulos Node.js.

Se concluye finalmente que se cumplieron satisfactoriamente con los requeri-mientos planteados por la empresa y se han obtenido conocimientos valiosos parala formación profesional del autor.

50 Capítulo 5. Conclusiones

5.2. Próximos pasos

A continuación se enumeran las tareas que se pueden realizar a futuro para seguirañadiendo valor al producto.

51

Bibliografía

[1] Asm.js. Asm.js Technical Specification. Disponible: 2016-11-09. URL:http://asmjs.org/spec/latest.

[2] Google Inc. Chrome Native Client. Disponible: 2016-11-09. URL:https://developer.chrome.com/native-client.

[3] GYP. GYP User Documentation. Disponible: 2016-11-09. URL:https://gyp.gsrc.io/docs/UserDocumentation.md.

[4] JCM Standard; bi-directional serial interface. Rev. E. Japan Cash Machine Co.Ltd. 2007.

[5] Microsoft. Introduction to ActiveX Controls. Disponible: 2016-11-09. URL:https://msdn.microsoft.com/en-us/library/aa751972(VS.85).aspx.

[6] Node.js Foundation. Node.js Native Addons Documentation. Disponible:2016-11-09. URL: https://nodejs.org/api/addons.html.

[7] OpenHub. NaCL Proyect Main Repository Activity. Disponible: 2016-11-09.URL: https://www.openhub.net/p/NaCL-main.

[8] OpenHub. Node.js Proyect Main Repository Activity. Disponible: 2016-11-09.URL: https://www.openhub.net/p/node.

[9] Puloon PSCU Check Scanner Interface Specification. PL-PCSU0100C-003. Rev.2.2. Puloon Technology Inc. 2013.

[10] Puloon PSCU Check Scanner Product Specification. PL-PCSU100-002. Rev. 1.7.Puloon Technology Inc. 2011.

[11] U.are.U SDK Developer Guide. Version 2. DigitalPersona Inc. 2012.[12] U.are.U SDK Platform Guide for Linux. Version 2. DigitalPersona Inc. 2012.[13] U.are.U SDK Platform Guide for Windows. Version 2. DigitalPersona Inc.

2012.[14] USB HID Swipe Reader Technical Reference Manual. 99875191. Rev. 13.

Magtek Inc. 2012.

Biblioteca de software para terminal de...

Documents

Transcript of Biblioteca de software para terminal de...