Articulo IEEE Trabajo de Grado 607

SISTEMA INALÁMBRICO PARA LA REALIZACIÓN DE PEDIDOS, CONTROL DE INVENTARIO Y FACTURACIÓN CON APLICACIÓN PARA RESTAURANTES Y SIMILARES Juan David Uribe, Nicolás Revollo y Víctor Hugo Borrero Director: Elkin Eduardo García

Resumen — En este proyecto se realiza un sistema que permite tomar los pedidos de un restaurante, bar o similar, almacenándolos en una base de datos con el ánimo de utilizar esta información posteriormente, por ejemplo, para la facturación de cuentas. La adquisición de los pedidos es realizada por el mesero quien cuenta con un módulo llamado Wireless Order, este módulo se comunica de forma inalámbrica con un dispositivo central llamado Control Order, quien es el encargado de la recepción de los pedidos y el envío a un ordenador por medio del puerto USB. Dentro del ordenador los datos son manejados por los programas Visual Basic y Microsoft Access, el objetivo principal de este proyecto es disminuir el tiempo que tarda el mesero en llevar la orden a la cocina y realizar una adecuada organización de los datos utilizando bases de datos. Abstract— This project has been developed as a system in which the user can take orders in different places such as restaurants, pubs or clubs keeping it in a database that allows to use the information for example to make the receipts. Using the module “Wireless Order” the waiter places the order, this module has wireless communication to a central device called “Control Order”, which is in charge of taking the orders and send them to a computer through the USB bus, the database is managed by Visual Basic and Microsoft Access Software. The main objectives of this project are to decrease the time in which the waiter takes the order to the kitchen and to make appropriate organization of the information in a central database. Índice de Términos – Automatización de Restaurantes, Universal Serial Bus (USB), Transmisión de RF, Bases de Datos, Interfaz Gráfica Visual Basic.

I. INTRODUCCION

D

entro del rol de funcionamiento de restaurantes, bares y discotecas de gran tamaño y con un elevado número de clientes, se hace necesario crear un sistema que permita manejar la información de una forma más eficiente que la lograda con los procesos tradicionales. Para la correcta administración de este tipo de establecimientos es importante tener un acceso sencillo a información como: ventas por día, ventas realizadas por mesero, número de platos vendidos de cada tipo, cantidad de botellas vendidas de cada marca y tipo de licor, etc. Con este tipo de información se facilita realizar la contabilidad de los negocios, se pueden realizar análisis estadísticos que permiten hacer proyecciones sobre el comportamiento de la clientela, identificar cuales son los productos más vendidos, de cuales es necesario tener una mayor reserva y “medir” la capacidad de trabajo de los meseros según la cantidad de ventas realizadas. Por medio de este proyecto se desarrolló un sistema que proporciona las herramientas adecuadas para optimizar la administración y operación de restaurantes, bares, discotecas y establecimientos similares. Con el sistema creado se pueden realizar pedidos y la facturación de cuentas, al implementar una comunicación inalámbrica entre los módulos que componen el producto creado. Para el fortalecimiento del establecimiento es conveniente reducir los tiempos de atención al cliente, este tiempo puede ser dividido de la siguiente forma:

1. 2. 3.

Tiempo que tarda el mesero en ir a la mesa y entregar la carta. Tiempo que tarda el mesero en tomar el pedido. Llevar el pedido a la cocina y/o a la barra de bebidas.

4. 5.

Preparar los alimentos y/o bebidas. Llevarlos a la mesa.

Módulo LCD

M icrocontro lador Teclado

El primer y cuarto tiempo se pueden disminuir contratando más personal o reduciendo las labores de cada empleado, el segundo tiempo depende del cliente por lo cual disminuirlo está fuera del alcance del proyecto, mientras que el tercer y quinto tiempo dependen básicamente del mesero. Mediante el sistema que se diseñó, cada mesero va a suprimir el tercer tiempo, pues los pedidos serán enviados a la cocina y barra de bebidas de forma remota e inalámbrica, de esta forma se disminuirán las labores asignadas a cada mesero reduciendo también el primero de los tiempos y logrando así una mayor eficiencia en el proceso de servicio y atención al cliente. Por otra parte un problema frecuente que se presenta en este tipo de establecimientos, especialmente en bares y discotecas, consiste en que la cuenta de una mesa normalmente no la cancela solo una persona, sino que cada cliente cancela lo que consumió él y sus acompañantes; mediante una identificación con un número para cada cliente, se permite manejar un tipo de facturación personalizada ofreciendo un valor agregado al cliente final. El sistema desarrollado está compuesto por los siguientes módulos: •

•

Wireless Order: Utilizado por el mesero para tomar los pedidos de los clientes. Sus principales funciones son: Adquisición de pedidos, proveer los medios necesarios para la visualización de la información (Menú) y realizar la transmisión de la información mediante RF. Control Order: Es el módulo encargado de recibir la información que es transmitida por el Wireless Order, adicionalmente envía los datos a la base de datos que se encuentra en el PC a través del puerto USB.

II. DESARROLLO

E

l sistema realizado está dividido en dos bloques básicos que corresponden a cada uno de los módulos desarrollados, estos bloques son mostrados en la figura 1.

Receptor / Transm isor

WIRELESS ORDER

C O N T R O L

CONTROL ORDER

Receptor / Transm isor Microcontro lador USB

A C C E S O

COMPUTADOR

Módulo LCD

A L M icrocontro lador Teclado

Receptor /

M E D I O

SISTEMA OPERATIVO & ACCESS

Transm isor

WIRELESS ORDER

Figura 1. Diagrama en Bloques del Proyecto.

A. Módulo Wireless Order El bloque llamado Wireless Order representa el módulo con el cual cuenta cada mesero para realizar los pedidos, cada módulo de este tipo está dividido por varios bloques internos encargados de llevar a cabo funciones específicas. El elemento más importante de este módulo es el microcontrolador PIC 18F452 [1], es responsable del procesamiento de los datos y de la interacción con los otros elementos del módulo. El bloque Receptor / Transmisor de RF implementado con los dispositivos TLP / RLP434 [2], es el encargado de comunicarse con el módulo Control Order mediante modulación digital ASK [3], su función consiste en enviar los datos relacionados con los pedidos digitados por el mesero y realizar un Handshake con el Control Order indicando si la transmisión fue o no exitosa. El bloque de visualización está compuesto por el módulo LCD de 2 líneas, cada una con 16 caracteres, a través de este display se visualizan los mensajes o instrucciones para el usuario y los 16 productos almacenados en la memoria del microcontrolador que controla el módulo. La principal función de este bloque es mostrar los datos al usuario final de la forma más sencilla posible. El mesero interactúa con el Wireless Order mediante un teclado alfanumérico de 16 caracteres, escogiendo la información que desea transmitir acorde con el pedido de cada cliente. Este bloque se llamó “Adquisición de Pedidos”. El teclado utilizado en este bloque es un periférico de entrada y su comunicación con el microcontrolador es unidireccional Como se expuso anteriormente, una de las principales funcionalidades provistas por el Wireless Order permite enviar el pedido de forma inalámbrica mediante señales de RF utilizando modulación ASK [3], esta información se organizó

en dos bytes que contienen los siguientes datos: mesero que realizó el pedido, mesa en la que se encuentra el cliente, identificador de cliente y producto que se ordenó. En la figura 2 se observa el formato del datagrama enviado por el módulo Wireless Order al Control Order.

B. Módulo Control Order Las principales funciones del módulo Control Order son las siguientes: • •

Figura 2. Datagama utilizado para la comunicación entre el Wireless Order y Control Order.

El preámbulo está compuesto por 30 unos lógicos que se envían para lograr que el canal de comunicaciones se establezca y generar así una sincronización, después de este preámbulo se envía un bit de inicio, que es un cero lógico el cual indica que los próximos dos bytes que van a llegar son los datos del pedido. Se utiliza codificación por ancho de pulso para lograr la sincronización entre el transmisor y receptor, esta codificación consiste en enviar una señal de periodo constante y para la representación de datos binarios se modifica el ciclo útil de la señal, la representación de un uno lógico es la señal con ciclo útil de 0.75 y para la representación de un 0 lógico es la señal con ciclo útil de 0.25, en la figura 3 se observa la transmisión de 111010100.

Figura 3 Ejemplo de codificación por ancho de pulso de la señal binaria 111010100.

El pedido (datagrama) es enviado dos veces por el Wireless Order con el ánimo de proveer la redundancia necesaria para garantizar una comunicación libre de errores, cuando el Control Order recibe los dos datagramas los compara, si los dos bytes de información son iguales envía una señal de ACK indicando que el proceso de transmisión fue realizado exitosamente, si la comparación de la información muestra que los bytes recibidos no son iguales, enviará una señal de NAK, solicitando de esta forma una retransmisión que será realizada automáticamente por el Wireless Order involucrado en la comunicación. Si el módulo del mesero no recibe ninguna señal, él automáticamente retransmitirá la información, si nuevamente no obtiene ninguna respuesta mostrará un mensaje indicándole al mesero que ha ocurrido un error.

Transmisión y Recepción de mediante RF. Comunicación con el Ordenador.

datos

El módulo Control Order está compuesto por un bloque interno Receptor / Transmisor de RF encargado de comunicarse, mediante modulación ASK [3], con cada uno de los Wireless Order que se tengan activos en el establecimiento. Como se explicó en el literal A, se implementó un simple protocolo de handshake que le permite al mesero ser informado sobre posibles fallas de transmisión debido a colisiones y pérdida de información. Para la funcionalidad que provee la comunicación con el Ordenador en el que se encuentra la base de datos, se decidió utilizar el protocolo USB debido a las altas prestaciones de este bus como lo son: altas velocidades de transferencia, facilidad plugand-play, alta escalabilidad, Hot-pluggable y a la afinidad del mercado de la informática con este estándar. Debido a que la aplicación desarrollada no tiene altos requerimientos de velocidad para la transmisión de los datos entre el Control Order y el Ordenador, se decidió utilizar la tasa de transferencia Full-Speed definida en [4], de igual forma, como se transmite un volumen de datos pequeño en cada transferencia y no se tienen las necesidades de una aplicación “Real-Time” se utilizó el tipo de transferencia Interrupt [4]. El elemento más importante del módulo Control Order es el microcontrolador PIC 18F2550 [5], cuya principal característica es que posee los módulos necesarios para implementar la comunicación a través del puerto USB. Este microcontrolador facilita la implementación del estándar USB versión 2.0 mediante el SIE (Serial Interface Engine) y el transceptor interno que acondiciona las señales transmitidas a este puerto. Para la comunicación con el Ordenador a través del bus USB se configuraron cuatro endpoints y dos pipes en el módulo Control Order, los primeros dos endpoints (identificados con el número cero), son utilizados para las transferencias de Control que le permiten al Host USB obtener la información más relevante del dispositivo y configurarlo, los otros dos endpoints (identificados con el número uno), se utilizan para las transferencias por Interrupción en las cuales se envían los dos bytes descritos en el literal A. Cada uno de los endpoints configurados tiene un buffer en el que se almacena la información recibida o la

información que se quiere transmitir hacia el Host, estos buffers son independientes y cada uno es configurado y controlado por cuatro registros del microcontrolador que son conocidos como BD (Buffer Descriptor). La figura 4 muestra un ejemplo del buffer y BD asociado con el endpoint cero, la dirección del buffer en este caso es igual a 500H y el tamaño del paquete será de 40H = 64 bytes[5].

6. 7. 8.

ubicando al dispositivo en el estado “Dirección”. El Host pide los 18 bytes correspondientes al descriptor del dispositivo. El Host pide los 9 bytes del descriptor de configuración. El Host pide los descriptores de cadena si fueron especificados.

Cuando se ha terminado el octavo paso de este proceso el dispositivo estará configurado y listo para ser utilizado.

Figura 4. Ejemplo del Buffer y BD del endpoint Cero.

Básicamente la comunicación entre el Control Order y el Ordenador se realiza en dos posibles situaciones: • •

Cuando se configura el dispositivo. Cuando se envía la información relacionada con el pedido.

Cuando el dispositivo se conecta al puerto USB, el Host deberá configurarlo según sus características y requerimientos específicos, esta información se encuentra almacenada en varios descriptores que son enviados por el Control Order tras la solicitud del Host. El proceso mediante el cual se configura el dispositivo es conocido como Enumeración y está compuesto por los siguientes pasos: 1.

2.

3. 4.

5.

El Host o Hub detecta la conexión del dispositivo a través de las resistencias de pullup que éste posee. El Host espera por lo menos 100ms permitiendo que se termine el proceso de inserción y que sea estable la alimentación del dispositivo. En este estado el dispositivo está en el estado “Encendido”. EL Host reinicia el dispositivo para llevarlo al estado “Por Defecto”. En este momento el dispositivo se comunicará a través de la dirección por defecto cero. El Host pide los primeros 64 bytes del descriptor del dispositivo. Después de recibir los primeros 8 bytes del descriptor del dispositivo, el Host realiza otro reset del bus. Ahora el Host efectúa un comando para asignarle al dispositivo una dirección única,

Para la segunda situación se envía la información que recibió el Control Order a través de RF desde el módulo Wireless Order. Después de comprobar que los dos bytes de información llegaron sin errores, estos bytes son copiados en el espacio de la memoria del microcontrolador que es conocido como “USB RAM” en donde se encuentran los buffers de los endpoints. Mediante los registros de control de este buffer se configura la transmisión. En este momento el microcontrolador quedará esperando a que el Host lo atienda para enviar la información digitada por el mesero desde el módulo Wireless Order.

C. Base de Datos e Interfaz Gráfica Después de que se haya completado el proceso de enumeración al que se hace referencia en el literal B, el Host tiene la información completa de los descriptores de la función. El sistema operativo (SO), en este caso windows XP reconoce que el dispositivo conectado al puerto USB es de tipo Human Interface Device (HID) [6]. Para realizar con éxito el intercambio de información entre el dispositivo y el Host es necesario que éste use drivers tipo HID que se encuentran en el core de Windows XP. Los drivers que proporciona el SO son una agrupación de Applications Programming Interface (APIs) [7] que ejecutan diversas acciones sobre un mismo tema. El SO carga automáticamente todos los drivers que poseen funciones relacionadas para manejar dispositivos HID para que después puedan ser invocados desde lenguajes de alto nivel como Visual Basic. Para el desarrollo del software Control Order se usó la librería mcHID.dll de acceso gratuito en Internet. Esta librería fue desarrollada por Mecanique UK [8], y agrupa APIs especiales cuya principal función es la de facilitar la comunicación y el intercambio de información entre dispositivos HID que usan microcontroladores de la familia 18fxx5x, y el Host.

El programa que se desarrolló en Visual Basic consta básicamente de 2 secciones. La primera es el formulario donde está el programa principal que realiza todos los procedimientos y llamadas a las funciones y la segunda es un modulo de clase donde se realizan las declaraciones de las APIs y la base de datos. A continuación se explica como se invoca una funcion API [7], además de la estructura de la base de datos. Una función API se invoca a través de la sentencia Declare, donde se especifica en qué librería está la función, qué parámetros se le envían y qué tipo de variable retorna. Éstas pueden ser llamadas en cualquier momento de ejecución del programa si se declaran de manera global. Como se dijo anteriormente en éste módulo también se define y se invoca la base de datos, ésta se desarrolló en Microsoft Access que es una aplicación de Microsoft Office. La estructura correspondiente se ilustra en la siguiente tabla. CAMPO a0 a1 a2 a3 a4 a5 a6 a7 a8

DESCRIPCION

TIPO DE DATO Fecha/Hora

Hora en la que se tomó el pedido Fecha en la que se tomó el Fecha/Hora pedido Orden de pedido Texto Producto pedido Texto Mesero que realizó el Texto pedido Mesa a la cual corresponde Texto el pedido Cliente que realizó el Texto pedido Valor del producto pedido Moneda Muestra si está activo o Texto facturado Tabla 1. Estructura de la base de datos

En el formulario principal está el programa que permite interactuar con el dispositivo HID, a través de las funciones declaradas en el módulo de clase. El programa se puede dividir en 3 procesos importantes. El primero es el de conexión y desconexión, el segundo es de lectura y almacenamiento de la información en la base de datos y el tercero es la generación de reportes. 1.

Conexión y desconexión

En el momento en que se carga el formulario se invoca el API encargado de establecer la conexión con el dispositivo, si la función notifica que el proceso fue exitoso se procede a leer la información correspondiente de los identificadores del dispositivo. Para que el programa solamente funcione con nuestro producto, se declararon 2 variables que tienen el valor del ID del fabricante y el ID del producto que tiene el microcontrolador 18F2550 en su memoria de programa. Si estos valores coinciden,

el programa está listo para leer información y almacenarla en la base de datos, si no, el programa no inicializa. 2.

Lectura y almacenamiento de los datos

Cuando el Host en el ciclo de polling, atiende al dispositivo y éste tiene información para transmitirle, el driver encargado de la comunicación genera un mensaje de notificación. Una vez el programa haya sido notificado, invoca al API que se encarga de almacenar la información leída en un buffer de memoria del Host. A continuación los bytes transmitidos se copian en un vector donde se encuentran todos los datos enviados por el Wireless Order en transacciones anteriores. Cada posición del vector corresponde a un byte de información y se van almacenando según el orden de llegada, es decir el último byte que llegó está en la última posición del vector. Después de esto viene el proceso de decodificación. La penúltima posición del vector es el primer byte almacenado y éste contiene la información del mesero, el cliente y la mesa, mientras que la última posición es el segundo byte que contiene la información correspondiente al producto. Esto es mostrado en la interfaz gráfica y almacenado en la base de datos en los campos descritos anteriormente. 3.

Generación de reportes.

Después de tener la información de los pedidos almacenada en la base de datos, sigue el proceso de generación de reportes. Esto consiste en realizar búsquedas de registros que cumplan ciertos criterios. Estas búsquedas que se realizan sobre la base de datos se logran ejecutando sentencias SQL [9]. El resultado de la búsqueda será mostrada en la interfaz gráfica.

III. ESPECIFICACIONES A continuación se exponen las especificaciones eléctricas del módulo Control Order. • • • •

Voltaje de entrada: 12V DC. Corriente de entrada sin estar conectado al puerto USB: 14mA. Corriente de entrada estando conectado al puerto USB sin actividad RF: 32mA. Corriente de entrada estando conectado al puerto USB con actividad RF: 38mA.

Las especificaciones eléctricas del módulo Wireless Order se muestran a continuación: •

Voltaje de entrada: 8.4V DC.

•

•

•

•

Corriente de entrada sin estar encendida la luz del display y sin estar realizando transmisiones: 16mA. Corriente de entrada con la luz del display encendida y sin estar realizando transmisiones: 144mA. Corriente de entrada sin estar encendida la luz del display y realizando transmisiones: 33mA. Corriente de entrada con la luz del display encendida y realizando transmisiones: 161mA.

Debido a que la batería que se está utilizando es recargable con una autonomía de 170mAh, suponiendo que el 80% del tiempo el modulo se encuentra sin realizar transmisiones y con la luz del display apagada, el 15% del tiempo el módulo se encuentra sin realizar transmisiones y con la luz del display encendida, el 4% del tiempo el módulo se encuentra realizando transmisiones con la luz del display apagada y el 1% del tiempo el módulo se encuentra realizando transmisiones y con la luz del display prendida, se obtendría que la que la corriente promedio sería de 37.33 mA. Si la corriente promedio es de 37.33mA y la autonomía de duración de la batería es de 170mAh, obtendríamos que la carga de la batería dura en promedio 4.55 horas, para determinar este tiempo se utilizó la ecuación 1.

170mAh = 4.55h 37.33mA

(1)

La velocidad de transmisión de datos desde el Wireless Order al Control Order y viceversa es de 1Kbps teniendo en cuenta que el datagrama cuenta con 30 bits de preámbulo, uno de inicio y 16 de datos, obtendríamos que la velocidad de transmisión de solo los datos es de 340 bps, esta velocidad se calcula en la ecuación número 2.

16bits × 1Kbps ≈ 340bps (2) 47bits El datagrama total tiene 47bits de tamaño, teniendo en cuenta que cada tiempo de bit es de 1 mseg, se tiene que el envió de un datagrama dura 47mseg.

IV. RESULTADOS

C

on el ánimo de mostrar los resultados obtenidos, es necesario realizar pruebas que permitan ver su funcionamiento en ambientes

similares a los presentados en restaurantes, bares y similares. Se realizaron tres pruebas para determinar el alcance de RF en tres escenarios distintos, el primero de ellos al aire libre, el segundo en un ambiente cerrado y el último en un ambiente cerrado pero ubicando el Control Order y los Wireless Order en pisos distintos. A continuación se exponen los resultados obtenidos. A. Pruebas en ambiente cerrado – Mismo Nivel Las pruebas realizadas en este ambiente consistieron en realizar 40 transmisiones desde dos puntos distintos (con dos Wireless Order distintos) de un apartamento con un solo nivel y un área aproximada de 104m2, específicamente se realizaron 3 pruebas de este tipo atravesando como máximo 4 paredes.

Tabla 2. Resultados Obtenidos Pruebas Ambiente Cerrado – Mismo Nivel

Desde cada uno de los módulos Wireless Order se realizaron 20 transmisiones en cada una de las pruebas, obteniendo un total de 120 transmisiones en el ambiente cerrado – mismo nivel. La cuarta columna de la tabla anterior (Cantidad Errores) indica cuantas transmisiones, de las 20 realizadas, fueron “No Exitosas” en la primera transmisión y requirieron que el “mesero” retransmitiera el pedido enviado. Una transacción “No Exitosa” se debe entender como una transmisión en la que se envió un pedido, dicho pedido no llegó al módulo Control Order y el “mesero” fue informado de esto para que retransmitiera el pedido tomado. En la quinta columna (Retransmisiones x 1) se indica cuantos pedidos de los que no llegaron en la primera transmisión, llegaron correctamente en la segunda transmisión. La sexta columna (Retransmisiones x 2) se muestra cuantos pedidos de los que no llegaron en la primera, ni en la segunda transmisión llegaron en la tercera transmisión. Aunque las 120 transmisiones no se realizaron desde los mismos puntos, y el lector puede considerar como un error manejar los datos obtenidos como si provinieran de una única prueba, es importante recordar que el objetivo de estas tres pruebas consistía en calcular el porcentaje de fallas en las que se requiere realizar retransmisiones para el ambiente cerrado – mismo nivel.

La ecuación 3 muestra un cálculo del porcentaje de transmisiones en las que se recibió exitosamente la información en el primer intento.  120 − 9  PEXITO PRIMERA TX =   *100% = 92.5%  120 

(3)

La siguiente ecuación muestra el cálculo del porcentaje de transmisiones en las que se recibió exitosamente la información en el segundo intento. Como se mostró en la tabla 2, 7 transmisiones no fueron exitosas en el primer intento. PREQUERIR UNA RETRANSMISIÓN

 7  =  *100% = 5.83%  120 

(4)

La ecuación 5 muestra el cálculo del porcentaje de “pedidos” en los que se requirieron realizar 2 retransmisiones para que la información llegara al módulo Control Order. Como se mostró en la tabla 2, dos “pedidos” se debieron retransmitir dos veces para que fueran exitosas.  2  PREQUERIR DOS RETRANSMISIÓNES =   *100% = 1.66%  120 

distancia del Control Order, el resultado de esta prueba se muestra en la tabla 4.

(5)

Para fines comerciales consideramos que el porcentaje de éxito de transmitir en el primer intento tiene que ser aproximadamente del 90%, siendo consecuentes con esta especificación, se puede concluir que el sistema desarrollado satisface las expectativas de un usuario final promedio. B. Pruebas en ambiente cerrado – Distintos Niveles Algunos de los restaurantes y bares operan en construcciones con más de una piso, para simular este escenario se decidió realizar pruebas en una casa, realizando transmisiones desde dos distintos pisos, el Control Order siempre permaneció en el primer piso y se realizaron transmisiones desde los Wireless Order a un piso de distancia y luego a dos pisos de distancia del Control Order, la primera prueba consistió en realizar 64 pedidos desde cada Wireless Order a un piso de distancia del Control Order, el resultado se muestra en la tabla 3.

Tabla 4. Resultados Obtenidos Pruebas a dos pisos de distancia

Con esta prueba se obtiene el siguiente porcentaje de éxito para el primer intento.

128−3 PEXITOPRIMERA *100%=97.65% TX =  128 

(6)

Mediante estas pruebas se demostró que el sistema tiene la capacidad de realizar pedidos desde pisos distintos, obteniendo un alto porcentaje de transmisiones exitosas en el primer intento. Estos resultados se obtienen como consecuencia de la frecuencia de transmisión utilizada en los módulos desarrollados, debido a que el tamaño de la longitud de onda es grande en comparación con la longitud de onda para transmisores que operan a una frecuencia mayor, esta longitud de onda mayor resulta en que las señales no se atenúan de forma considerable cuando atraviesan obstáculos. C. Pruebas en ambiente abierto El objetivo para el cual se diseñaron y se realizaron estas pruebas, es saber la máxima distancia a la cual el Control Order puede recibir información de manera correcta de los 2 módulos Wireless Order en un ambiente al aire libre. Para lograr esto se ubicó el Control Order en un sitio donde no hubiera interferencia visual por parte de ningún objeto. A continuación, se fijaron cuatro puntos de referencia separados entre ellos 10 m para que desde ahí se hicieran las transmisiones de pruebas. En la tabla 5 se muestran los resultados para el módulo 1 y en la tabla 6 para el módulo2.

Tabla 5. Resultados obtenidos Wireless Order 1

Tabla 3. Resultados Obtenidos Pruebas a un piso de distancia

La segunda prueba consistió en realizar 64 pedidos desde cada Wireless Order a dos pisos de

Tabla 5. Resultados obtenidos Wireless Order 2

En cada punto de referencia se hicieron 16 transmisiones que corresponden al número de platos disponibles en el Wireless Order. Para el módulo 1 a los 10m todas las transmisiones fueron exitosas, a los 20m y a los 30m 2 transmisiones fueron no exitosas, y a los 40m ninguna transmisión fue exitosa. Para los 20m solo fue necesaria una retransmisión y para los 30m dos retransmisiones. Para el modulo 2 a los 10 m todas las transmisiones fueron exitosas, a los 20 m hubo un error que con la primera retrasmisión fue suficiente para recibir con éxito el pedido, lo mismo sucedió a los 30 m, y a los 40 m no se recibió ningún pedido de las 16 transmisiones realizadas. Como a los 40 m no fue exitosa ninguna transmisión y a los 30 m fue alto el porcentaje de las transmisiones exitosas se hicieron pruebas desde los 35 m con los dos módulos enviando información de manera intercalada evitando las transmisiones simultáneas. Transmitimos 2 veces cada producto, completando 32 por cada módulo y 64 en total. En este caso 37 transmisiones fueron exitosas y 27 erróneas. Después de realizar los cálculos de porcentaje de transmisiones exitosas en el primer intento y como se dijo anteriormente, concluimos que la máxima distancia a la cual el porcentaje de envíos exitosos en el primer intento es de 90% es de 30m. D. Pruebas Realizadas Base de Datos Para evaluar el desempeño de la base de datos y verificar su correcto funcionamiento no se requirieron realizar pruebas adicionales, se reutilizó la información recolectada en las pruebas explicadas en el literal A. Como se mencionó anteriormente se realizaron 120 transmisiones en el Ambiente Cerrado – Mismo Nivel, 384 en el Ambiente Cerrado – Distintos Niveles y 192 en el Ambiente Abierto, para obtener un total de 696 transmisiones o pedidos, el 100% de los datos enviados desde los módulos Wireless Order fueron almacenados en la base de datos sin presencia de errores. E. Pruebas Sistema Operativo Las pruebas que se hicieron con respecto al sistema operativo consistieron en verificar que el sistema operativo en nuestro caso el Windows Xp[5], detectara el Control Order cuando es conectado mediante un puerto USB por primera vez, en la figura 64 se muestra el mensaje de detección arrojado por el Windows XP cuando se conecta el Control Order por primera vez, esta prueba se hizo 25 veces y en las 25 veces el sistema operativo detectó correctamente el

Control Order, para hacer esta prueba se hace necesario desinstalar los controladores del Control Order cada vez que se conecte y desconecte , ya que si se conecta por segunda vez sin desinstalar los controladores este detecta el dispositivo, pero no le es necesario instalarlo.

Figura 5. Mensaje de WinXP cuando reconoce por primera vez el Control Order.

La segunda prueba que se realizó consistió en conectar y desconectar el Control Order en 50 ocasiones sin desinstalar los controladores, el 100% de las pruebas fueron exitosas.

V. CONCLUSIONES El Sistema realizado cumple con los objetivos propuestos en el Proyecto de Grado, ya que desde los módulos Wireless Order se están realizando los pedidos logrando identificar la mesa, el cliente específico y el producto solicitado, también los datos están siendo reconocidos e ingresados satisfactoriamente a la base de datos y en ésta se generan los reportes de ventas, adicionalmente el código de detección de errores implementado para la transmisión de RF fue exitoso, ya que el operador del módulo Wireless Order sabrá cuando hay un error. Los procesos de un restaurante, bar o similar que fueron optimizados mediante este proyecto fueron los siguientes: Eliminación del tiempo requerido por el mesero para llevar el pedido a la cocina, supresión de los medios tradicionales para la toma de pedidos, las cuentas de una misma mesa son separadas permitiendo crear cuentas independientes y la información de los pedidos se centraliza en un solo archivo permitiendo un fácil acceso a los usuarios (por ejemplo el administrador). Este proyecto de Grado es un importante avance para el desarrollo de la automatización de restaurantes en Colombia, ya que el precio de sistemas similares a nuestro proyecto están alrededor de 3 ó 4 veces el precio de nuestro sistema, esto se estimó según [11], esta relación costo beneficio hace factible que los propietarios de restaurantes opten por realizar una automatización en su establecimiento. La comunicación a través del puerto USB se realizó de forma exitosa a la tasa de transferencia Full-Speed [4], aprovechando todas las prestaciones de este bus como lo son las

facilidades plug-and-play, Hot pluggable, alta escalabilidad y la afinidad del mercado de la informática con este estándar. El sistema desarrollado puede ser mejorado en varios aspectos con el objetivo de acercarse más a los requerimientos de un producto comercial, como por ejemplo, aumentar la cantidad de productos, utilizar transceptores de RF que soporten comunicación full duplex, implementar un sistema para que el cliente pueda realizar sus pagos por medio de tarjeta débito o crédito a través del módulo Wireless Order, efectuar un código de redundancia cíclica para la corrección de errores, entre otros. El sistema desarrollado se desempeña de forma exitosa realizando transmisiones de datos en ambientes con obstáculos (paredes, muebles, placas de concreto, electrodomésticos, puertas, etc), alcanzando las distancias necesarias para cubrir los distintos ambientes de diferentes tipos de restaurantes (campestres, cerrados, mixtos, etc). En caso de requerir mayores distancias de transmisión se pueden reemplazar los transmisores de RF por unos de mayor potencia, como por ejemplo el TLP434A fabricado por [12], estos transmisores son compatibles con los receptores utilizados en este proyecto, de esta forma su adaptación es muy sencilla. Este proyecto está diseñado para optimizar las tareas de un restaurante, bar o similar, adicionalmente, el sistema desarrollado puede adaptarse a otro tipo de aplicaciones que requieran transmitir información de forma remota desde múltiples puntos hacia un ordenador para ser procesada posteriormente. Algunos ejemplos de estas aplicaciones se presentan en cultivos de flores, supermercados, bodegas, etc. El esquema diseñado para la transmisión de información a través de RF fue exitoso, se implementó un sencillo sistema de redundancia que reconoce la presencia de errores, retransmitiendo la información desde el Wireless Order de forma automática e informándole al mesero cuando se vuelve a presentar un error para que éste retransmita el pedido de forma manual. VI. REFERENCIAS [1] Microchip, Inc. Microprocessor PIC 18F242/252/442/452 User’s Manual Part Number: 39564a. [2] Laipac, Inc. Datasheet RLP/TLP 434, dispositivos de transmisión inalámbrica, disponible en Internet en http://www.laipac.com.

[3] M. Schwartz, Information Transmission, Modulation, and Noise, 4/e, McGraw Hill, 1990. [4] Universal Serial Bus Specification, Revision 2.0, April 27 / 2000. Disponible en internet en www.usb.org . [5] Microchip, Inc. Microprocessor PIC 18F2455/2550/4455/4550 User’s Manual Part Number: mc671uk. [6] Device Class Definition for Human Interface Devices, Version 1.11, Junio 27 / 2001. [7] http://www.msdn.microsoft.com, información sistemas operativos Microsoft. [8] http://www.mecanique.co.uk/ Proveedores de software [9] http://www.sql.org Información de lenguage de acceso a bases de datos. [10] Los Restaurantes de la economía Colombiana, ACODRÉS – Asociación Colombiana de la industria Gatronómica. [11] Soluciones Moviles, Tango Software House Inc, disponible en Internet en http://www.tangosofthouse.com [12] Laipac, Inc. Datasheet RLP/TLP 434, dispositivos de transmisión inalámbrica, disponible en Internet en http://www.laipac.com..