Restaurante Wireless - up.edu.br · Gostaria de agradecer em primeiro lugar a Deus, pois não fosse...

63
Centro Universitário Positivo - UnicenP Núcleo de Ciências Exatas e Tecnológicas – NCET Engenharia da Computação João Marcos Manzo Restaurante Wireless Curitiba 2005

Transcript of Restaurante Wireless - up.edu.br · Gostaria de agradecer em primeiro lugar a Deus, pois não fosse...

Centro Universitário Positivo - UnicenP

Núcleo de Ciências Exatas e Tecnológicas – NCET

Engenharia da Computação

João Marcos Manzo

Restaurante Wireless

Curitiba 2005

Centro Universitário Positivo - UnicenP Núcleo de Ciências Exatas e Tecnológicas – NCET

Engenharia da Computação João Marcos Manzo

Restaurante Wireless

Monografia apresentada à disciplina de

Projeto Final, como requisito parcial à

conclusão do Curso de Engenharia da

Computação. Orientador: Prof. Luiz

Carlos Albini

Curitiba 2005

ii

TERMO DE APROVAÇÃO

João Marcos Manzo

Restaurante Wireless

Monografia aprovada como requisito parcial à conclusão do curso de

Engenharia da Computação do Centro Universitário Positivo, pela seguinte

banca examinadora:

PROF. LUIZ CARLOS ALBINI

PROF. MAURÍCIO PERRETTO

PROF. MARCELO MIKOSZ

Curitiba, 06 de novembro de 2005

iii

AGRADECIMENTOS

Gostaria de agradecer em primeiro lugar a Deus, pois não fosse Sua vontade

não teria conseguido realizar esse projeto.

Quero também agradecer minha mulher Fernanda Pinheiro da Silveira por ter

sido compreensiva comigo em todos meus difíceis momentos em que estive

trabalhando em cima do projeto me agüentando de mal-humor e estressado pelo

mesmo motivo. Todas as suas frases de incentivo me ajudaram a continuar e levar

esse projeto adiante.

Agradeço aos meus pais que possibilitaram minha caminhada até esta

importante etapa da minha vida que é a graduação. Sempre me apoiando e

incentivando. Aproveito para dizer que todas as orações de minha mãe surtiram efeito

e consegui chegar até aqui.

Aproveitando a oportunidade agradeço a todos os meus amigos e colegas que

conviveram comigo durante todos esses anos por um lado difíceis de passar e por

outros muito valiosos. Agradeço também ao não só professor como também amigo

Maurício Perretto por sempre dar a atenção e não deixar na mão.

Agradeço ao meu professor orientador pela paciência em suas orientações e também

por ter apostado e acreditado na idéia do projeto. Agradeço também ao professor José

Carlos da Cunha que sempre esteve disposto a ajudar e incentivar a continuação do

projeto.

SUMÁRIO

I Lista de Tabelas e Quadros .................................................................................... ii II Lista de Ilustrações .................................................................................................iii III Lista de Siglas ........................................................................................................ iv IV Resumo................................................................................................................... v V Abstract .................................................................................................................. vi 1. Introdução............................................................................................................. 1

1.1 Motivação...................................................................................................... 2 1.2 Definição do trabalho..................................................................................... 2 1.3 Contextualidade nos dias atuais.................................................................... 3 1.4 Descrição das principais funcionalidades ...................................................... 4 1.5 Tecnologias utilizadas na implementação ..................................................... 4

2. Fundamentação Teórica ....................................................................................... 6 2.1. Comunicação Wireless.................................................................................. 6 2.2. Teoria de Sotftware ....................................................................................... 8

2.2.1. Banco de dados relacional..................................................................... 8 2.2.2. Protocolos de comunicação................................................................. 11 2.2.3. Linguagem C++ - Orientação a objetos ............................................... 12

2.3. Teoria de Hardware..................................................................................... 13 2.3.1. Display gráfico GLCD .......................................................................... 13 2.3.2. Transceiver.......................................................................................... 14 2.3.3. Microcontrolador.................................................................................. 15

3. Especificação...................................................................................................... 17 3.1. Especificação do hardware.......................................................................... 17

3.1.1. Teclado................................................................................................ 18 3.1.2. GLCD .................................................................................................. 18 3.1.3. Módulo Transceiver ............................................................................. 20 3.1.4. Microcontrolador.................................................................................. 21 3.1.5. Computador Servidor........................................................................... 22

3.2. Especificação do software........................................................................... 23 3.2.1. Banco de dados................................................................................... 24 3.2.2. Protocolo de comunicação Wireless .................................................... 24 3.2.3. Estimativa de Custos Para o Projeto.................................................... 26

4. Projeto ................................................................................................................ 28 4.1. Projeto de Hardware.................................................................................... 28

4.1.1. Módulo Teclado ................................................................................... 28 4.1.2. Módulo Display .................................................................................... 28 4.1.3. Módulo Transceiver ............................................................................. 29 4.1.4. Módulo Microcontrolador ..................................................................... 29 4.1.5. Lista de Materiais................................................................................. 30

4.2. Projeto do Software..................................................................................... 31 4.2.1. Casos de uso....................................................................................... 31 4.2.2. Diagrama de Classes .......................................................................... 32 4.2.3. Diagramas de seqüência ..................................................................... 34 4.2.4. Banco de dados................................................................................... 36

4.3. Projeto do Firmware .................................................................................... 41 4.4. Projeto do Protocolo de Comunicação ........................................................ 43

5. Resultados.......................................................................................................... 44 6. Conclusão........................................................................................................... 46 7. Referências Bibliográficas................................................................................... 47 8. Glossário............................................................................................................. 48 Anexos ....................................................................................................................... 49

ii

I LISTA DE TABELAS E QUADROS

TABELA 1 – APLICAÇÕES E BANDAS ............................................................................................. 7 TABELA 2 – ESTRUTURA DO BANCO DE DADOS ............................................................................ 9 TABELA 3 – ESTIMATIVA DE CUSTO DO CLIENTE........................................................................ 26 TABELA 4 – ESTIMATIVA DE CUSTO DO SERVIDOR ..................................................................... 26 TABELA 5 – MÓDULOS DO HARDWARE....................................................................................... 28 TABELA 6 – SINAIS REFERENTES AO MÓDULO (TECLADO)......................................................... 28 TABELA 7 – SINAIS REFERENTES AO MÓDULO (DISPLAY). ......................................................... 28 TABELA 8 – SINAIS REFERENTES AO MÓDULO (TRANSCEIVER).................................................. 29 TABELA 9 – SINAIS REFERENTES AO MÓDULO (DISPLAY). ......................................................... 29 TABELA 10 – LISTA DE COMPONENTES ....................................................................................... 30 TABELA 11 – RELAÇÃO DE TABELAS DO BANCO DE DADOS ....................................................... 37 TABELA 12 – DESCRIÇÃO DA TABELA TB_CLIENTES.............................................................. 37 TABELA 13 – DESCRIÇÃO DA TABELA TB_CONTA................................................................... 37 TABELA 14 – DESCRIÇÃO DA TABELA TB_FUNCIONARIOS................................................... 37 TABELA 15 – DESCRIÇÃO DA TABELA TB_HISTORICO_PEDIDOS ........................................ 38 TABELA 16 – DESCRIÇÃO DA TABELA TB_INGREDIENTES.................................................... 38 TABELA 17 – DESCRIÇÃO DA TABELA TB_LOG_MENSAGENS.............................................. 38 TABELA 18 – DESCRIÇÃO DA TABELA TB_MESAS ................................................................... 38 TABELA 19 – DESCRIÇÃO DA TABELA TB_PEDIDOS_PENDENTES....................................... 38 TABELA 20 – DESCRIÇÃO DA TABELA TB_PRATOS ................................................................. 39 TABELA 21 – DESCRIÇÃO DA TABELA TB_TIPO_CARDAPIO ................................................. 39 TABELA 22 – DESCRIÇÃO DA TABELA TB_TIPO_ORIGEM_MSG ........................................... 39 TABELA 23 – DESCRIÇÃO DA TABELA TB_TIPO_PAGAMENTO............................................. 39 TABELA 24 – DESCRIÇÃO DA TABELA TB_TIPO_PRATO......................................................... 39 TABELA 25 – DESCRIÇÃO DA TABELA TB_TIPO_REQUISICAO.............................................. 39 TABELA 26 – DESCRIÇÃO DA TABELA TB_TIPO_SERVICO..................................................... 40 TABELA 27 – DESCRIÇÃO DA TABELA TB_PEDIDO_CONTA .................................................. 40 TABELA 28 – DESCRIÇÃO DA TABELA TB_PEDIDO_PRATO................................................... 40 TABELA 29 – DESCRIÇÃO DA TABELA TB_SATISFACAO........................................................ 40 TABELA 30 – DESCRIÇÃO DA TABELA TB_TIPO_ENCERRADO ............................................. 40 TABELA 31 – DESCRIÇÃO DO PROTOCOLO DE COMUNICAÇÃO ................................................... 43

iii

II LISTA DE ILUSTRAÇÕES

FIGURA 1 – ESQUEMA BÁSICO DO PROJETO .................................................................................. 2 FIGURA 2 – EXEMPLO DE UMA ONDA MODULADA EM ASK, FSK E PSK..................................... 6 FIGURA 3 – ESTUDO DO PRINCÍPIO DE HYUGENS.......................................................................... 8 FIGURA 4 – MODELO ER............................................................................................................. 10 FIGURA 5 – EXEMPLO DE ESTRUTURA DE UM PROTOCOLO......................................................... 11 FIGURA 6 – ILUSTRAÇÃO DE UM GLCD...................................................................................... 13 FIGURA 7 – ILUSTRAÇÃO EXEMPLO DE UM TRANSCEIVER ......................................................... 14 FIGURA 8 – ARQUITETURA INTERNA DE UM PROCESSADOR RISC ............................................. 16 FIGURA 9 – ESQUEMA BÁSICO DO PROJETO ................................................................................ 17 FIGURA 10 – TECLADO DE MEMBRANA / CORTE ......................................................................... 18 FIGURA 11 – ESQUEMA PARA USO DO DISPLAY.......................................................................... 19 FIGURA 12 – DIAGRAMA EM BLOCOS DO MÓDULO TRANSCEIVER ............................................. 20 FIGURA 13 - PINAGEM DO MICROCONTROLADOR 8051 .............................................................. 22 FIGURA 14 – TELA DE LOGIN DO SISTEMA .................................................................................. 23 FIGURA 15 – TELA PRINCIPAL DO SISTEMA................................................................................. 24 FIGURA 16 - DIAGRAMA DE CASOS DE USO................................................................................. 31 FIGURA 17A – DIAGRAMA DE CLASSES DO SISTEMA (CLASSES DE NEGÓCIO). ........................... 32 FIGURA 17B – DIAGRAMA DE CLASSES DO SISTEMA (CLASSES DE BROKERS). ........................... 33 FIGURA 18 – DIAGRAMA DE SEQÜÊNCIA (INCLUIR PRATO). ....................................................... 34 FIGURA 19 – DIAGRAMA DE SEQÜÊNCIA (PESQUISAR PRATO). .................................................. 34 FIGURA 20 – DIAGRAMA DE SEQÜÊNCIA (ATUALIZAR PRATO). ................................................. 35 FIGURA 21 – DIAGRAMA DE SEQÜÊNCIA (EXCLUIR PRATO). ...................................................... 35 FIGURA 22 – DIAGRAMA DE SEQÜÊNCIA (GERENCIAR RESTAURANTE). .................................... 35 FIGURA 23 –MODELO ENTIDADE RELACIONAMENTO ................................................................. 36 FIGURA 24 – FLUXOGRAMA DE FUNCIONAMENTO DO FIRMWARE. ............................................ 41 FIGURA 25 – DIAGRAMA DE ESTADOS DO FIRMWARE. ............................................................... 42 FIGURA 26 – TESTE FUNCIONAL DO SISTEMA. ............................................................................ 44 FIGURA 27 – TESTE DE PROTOCOLO DO SISTEMA ....................................................................... 45

iv

III LISTA DE SIGLAS

NCET- Núcleo de Ciências Exatas e Tecnológicas

Wi-Fi – Wireless Fidelity

UNICENP – Centro Universitário Positivo

WLAN – Wireless Local Area Network

RF – Rádio Freqüência

FSK – Frequency Shift Keying

ASK – Amplitude Shift Keying

PSK – Phase Shift Keying

SGBD – Sistemas Gerenciadores de Banco de Dados

SQL – Structured Query Language

ER – Entidade / Relacionamento

IP – Internet Protocol

TCP – Transmission Control Protocol

UDP – User Datagram Protocol

FTP – File Transfer Protocol

SMTP – Simple Mail Transfer Protocol

RTP – Real-time transfer protocol

I/O – Input / Output

ULA – Unidade Lógica Aritmética

RAM – Random Access Memory

ROM – Read Only Memory

PC – Program Counter

CISC - Complex Instruction Set Computer

RISC - Reduced Instruction Set Computer

LSI – Large Scale of Integration

EEPROM - Electrically Erasable Programmable Read-only Memory

JTAG – Joint Test Action Group

SRAM – Static Random Access Memory

UART - Universal Asynchronous Receiver/Transmitter

DPTR – Data Pointer

PSEN - Program Store Enable

v

IV RESUMO

O trabalho visa a implementação de um sistema de comunicação entre clientes

e o atendimento de um restaurante. Para evitar o atraso de ter que esperar que um

garçom venha até a mesa, ou até de que não se encontre um garçom no momento

desejado. O cliente sem sair do lugar envia um pedido diretamente para a cozinha e

aguarda que o pedido lhe seja entregue prontamente.

Desta forma, o cliente fica mais satisfeito, com uma melhor qualidade no

atendimento sem dispensar o trabalho de um garçom, servir efetivamente. O sistema

apenas efetua o trabalho de anotar os pedidos dos clientes, ficando o garçom com a

função apenas de levar o pedido até sua mesa.

Todas as mesas possuirão o sistema instalado e farão uma comunicação sem-

fio (Wireless) com a cozinha diretamente. Onde assim o pedido entrará em uma fila de

prioridades por ordem de chegada.

Palavras-chave: Wireless; Restaurante.

vi

V ABSTRACT

Communication system between the clients and the restaurant. To prevent the

delay to wait a waiter even comes to the table or of that if he does not find a waiter at

the desired moment, the customer without leaving his place, directly sends an order for

the kitchen and waits that the order is delivers to it readily.

Of this form the customer is more satisfied with one better quality in the

attendance without excusing the work of a waiter, to serve effectively. The system only

inhibits waiter of the restaurant to write down the order of the customers, being with the

function to only take the order until its table.

All the tables will have installed a system and will make a Wireless

communication directly with the kitchen. Where thus the order will enter in a queue of

priorities for arrival order.

Key-Words: Restaurant, Wireless.

1

1. Introdução

Normalmente quando vamos a um restaurante o atendimento se procede da

seguinte forma:

• O cliente chega ao restaurante e senta em uma mesa qualquer.

• Em seguida, um garçom traz o cardápio até a mesa e sai dando um tempo

para o cliente fazer a escolha do pedido.

• O cliente já sabendo o que será pedido, solicita ao garçom que anote seu

pedido e o leve até a cozinha onde será inserido no final de uma fila FIFO até

que a comida chegue até sua mesa.

• Ao final o cliente solicita novamente o garçom para que lhe traga a conta ou ele

mesmo vai até o caixa e efetua o pagamento.

Salvo alguns outros itens que poderiam ser inseridos nesse processo, tudo funciona

basicamente dessa maneira. E facilmente percebe-se que quase que a totalidade

desses itens poderiam ser automatizados, utilizando um sistema de pedidos

automático onde o próprio cliente cuidaria de seus pedidos, deixando para o garçom

apenas o trabalho de levar o pedido até a mesa, melhorando assim a qualidade no

serviço e no atendimento.

2

1.1 Motivação

A fim de melhorar a qualidade do serviço de atendimento em restaurantes surgiu a

idéia de automatizar todo o processo operacional antes realizado pelos garçons.

Deixando a eles apenas a simples tarefa de levar o pedido até a mesa.

Com base nessa idéia, utilizar recursos não estudados no curso é extremamente

vantajoso para a área técnica profissional. Para o projeto em questão, a comunicação

sem fio (Wireless) - largamente utilizada em vários ramos da tecnologia -, é um

conhecimento de grande valor. Conseqüentemente, o projeto final pode ser

aproveitado para aprender essa tecnologia tendo como possibilidade aprimorar os

conhecimentos nessa área e juntamente estruturar uma base profissional concreta.

A comunicação Wireless se dá de forma bastante abrangente no projeto em

questão. Envolvendo protocolos de comunicação, controle de erros, endereçamento,

controle de fluxo de dados e tratamento de colisões.

Não só comunicação Wireless, mas o projeto inclui banco de dados, software

cliente/servidor e conhecimentos de Displays gráficos. Todos esses componentes

juntos fazem deste, um projeto completo e de grande valia para o aprendizado.

1.2 Definição do trabalho

O projeto consiste basicamente em duas partes representadas pela Figura 1:

• Um cliente (mesas) que será o responsável pela solicitação dos pedidos.

• Um servidor que atenderá a todas as solicitações dos clientes.

Figura 1 – Esquema básico do projeto

Como comentado anteriormente, ao chegar no restaurante, existe todo um

processo normal desde a chegada do cliente ao restaurante até sua saída. Observou-

3

se que muitos pontos desse processo elementar podem ser automatizados

melhorando o atendimento. O projeto funcionará da seguinte forma:

• O Cliente chega ao restaurante e senta-se na mesa desejada.

• Ao invés de o cliente ser recebido na mesa por um garçom trazendo-lhe o

cardápio, o cliente acessará diretamente o Menu de forma digital, escolhendo

todas as opções de seu pedido e enviando para um servidor (cozinha).

• Feito o pedido o cliente aguardará normalmente que um garçom traga-lhe tudo

que foi solicitado.

• Após a refeição o cliente solicita no sistema que a conta de sua mesa seja

devidamente fechada para iniciar o processo normal de pagamento.

Toda a comunicação envolvida no trâmite é Wireless. A comunicação do par

transmissor/receptor instalado no servidor terá uma comunicação serial com o mesmo.

Os dados de todos os pedidos serão armazenados em banco de dados, havendo

também a possibilidade de um cadastro de clientes. Logicamente, é através do banco

de dados que haverá o controle de contas do restaurante em questão. Um sistema de

controle de estoque, receitas e despesas não é parte deste projeto ficando apenas o

controle dos pagamentos efetuados pelos clientes.

A sistema instalado nas mesas terá uma interface amigável com o cliente, pois será

interativa e ocorrerá em um display gráfico onde a entrada de dados será feita através

de um teclado próprio.

1.3 Contextualidade nos dias atuais

O sistema do ‘Restaurante Wireless’ se encaixa bem no ambiente em que vivemos,

onde muitas pessoas freqüentam restaurantes com uma freqüência relativamente alta.

O processo operacional normal dos restaurantes de hoje gera alguns tipos de

transtornos tantos para os clientes, quanto para os garçons e o restaurante, por

exemplo:

• O cliente nem sempre é atendido quando deseja fazer uma solicitação.

• Existe, mesmo que com baixa freqüência, o fato do garçom esquecer de um

pedido do cliente.

• Troca de pedidos entre as mesas, pelo fato de o garçom ter anotado o pedido

de uma mesa como o de outra.

• O cliente não acompanha efetivamente as solicitações feitas em suas conta

que está em aberto, podendo não ter certeza de tudo o que foi pedido e está

especificado em sua conta.

4

Tais problemas seriam facilmente evitados com a automatização do processo

operacional do restaurante. Assim, demonstra-se que o sistema tem uma aplicação

prática nos dias de hoje.

1.4 Descrição das principais funcionalidades

O sistema tem de uma série de funcionalidades fundamentais que devem existir

para que seja um projeto comercialmente viável, dentre elas destacam-se:

Da parte do cliente:

• Opção de cadastro de clientes (não obrigatória);

• Caso seja cadastrado, opção de repetição de pedidos anteriores;

• Pedidos feitos pelo cliente através do sistema diretamente à cozinha;

• Opção de pedidos complementares, ocorridos durante a refeição;

• Pedido de fechamento de conta;

• Opção de “Estou Satisfeito”, para pararem de servir (funcional apenas se

Rodízio).

Da parte do servidor:

• Visualização de pedidos não finalizados pendentes de atendimento;

• Visualização gráfica das mesas do restaurante segundo a planta do

restaurante com código de cores para distinguir pedido de conta ou de

refeições;

• Relatório de valores arrecadados por período;

• Relação dos clientes cadastrados para atendimento personalizado;

• Opção de troca de cardápio;

• Opção de troca de funcionalidade (Buffet, Rodízio, A La Carte).

1.5 Tecnologias utilizadas na implementação

As principais tecnologias empregadas no sistema são:

• Comunicação Wireless com componentes de rádio freqüência (RF) –

Transceivers (Transmitters/Receivers).

• Representação em GLCD (Graphic Liquid Crystal Display).

• Comunicação serial.

• Banco de dados relacional.

• Utilização de Microcontroladores.

• Utilização de teclados para a navegação no cliente.

• Linguagem de programação C/C++.

5

Para a comunicação Wireless o componente DP1201-A da Xemics, para o GLCD o

componente KS-0108, para a comunicação serial foi utilizada a porta serial do

microcontrolador, para o banco de dados Firebird/Interbase (free) e finalmente para o

microcontrolador, o 8051 que possui sua arquitetura comum entre vários fabricantes,

por exemplo: Atmel e Siemens.

6

2. Fundamentação Teórica

2.1. Comunicação Wireless

É extremamente importante falar de como a comunicação Wireless surgiu e

qual a base de sua existência. Conhecer todo o estudo que está por trás dessa

tecnologia é de fundamental importância para o seu bom entendimento.

Do inglês a palavra Wireless significa sem-fio, ou seja, todos os equipamentos

que funcionam sem a necessidade de estarem fisicamente ligados através de um fio.

Por exemplo, a tecnologia Wireless pode ser utilizada para construir uma rede local

WLAN (Wireless Local Area Network) onde todos os terminais (computadores)

poderiam se comunicar sem a necessidade de cabos de rede. Dependendo da

freqüência as ondas possuem um comportamento diferente. Por exemplo, ondas de

altíssima freqüência (microondas) tendem a ser extremamente direcionais, ou seja, é

necessário que o transmissor e o receptor se ‘enxerguem’ fisicamente para que aja a

comunicação. E à medida que a freqüência da onda diminui menos direcional ela se

torna. As ondas de rádio, mais conhecidas como rádios freqüência (RF), podem

contornar obstáculos como prédios, montanhas, etc, devido à sua baixa freqüência.

Algumas áreas emergentes na comunicação Wireless são:

• Redes de computadores

• Monitoramento remoto e aquisição de dados.

• Controle de acesso e segurança.

Na comunicação Wireless existe o que é chamado de modulação. Modulação é

uma técnica onde a onda portadora é usada para transportar a informação de um lugar

para o outro. O sinal pode ser modulado em sua amplitude (ASK), fase (PSK) ou

freqüência (FSK) codificando-o no transmissor e decodificando-o no receptor. Um

exemplo é mostrado na Figura 2.

Figura 2 – Exemplo de uma onda modulada em ASK, FSK e PSK

7

Na comunicação sem-fio a freqüência varia enormemente dependendo do

dispositivo usado e da aplicação a qual se pretende utilizar essa tecnologia. A tabela 1

contém exemplos de aplicações de RF com suas respectivas faixas de freqüência:

Aplicação Banda Rádio AM Baixa transmissão de voz e dados

550 - 1600kHz

Controles remotos Telefones sem fio

49Mhz

Rádio FM 88 – 108Mhz Pager 150 – 170Mhz Sistemas de segurança Abridor de garagens Alarmes

260 – 470 Mhz

Celulares 824 - 849 MHz e 869 - 894 MHz

Comunicação Móvel Federal Banda Militar (propagação do espectro de telefones sem-fio)

902 - 928 MHz

Radio Militar Microondas Radio Amador

2.4 – 2.4385 GHz

Testes de alcance em instrumentação de radares Marinha

5.727 – 5.875 GHz

Radio Navegação 24 – 24.25 GHz

Tabela 1 – Aplicações e bandas

Geralmente, a freqüência típica para transmissão de dados na comunicação

sem-fio por radio freqüência é na faixa de 800 – 900Mhz do espectro eletromagnético.

Ondas de rádio são suscetíveis as interferências eletromagnéticas e não podem

atravessar obstáculos, apenas contorná-los aumentando a freqüência quando

necessário.

Pelo principio de Hyugens, uma onda se propaga no espaço, todos os pontos

primários de uma frente de onda irão formar pequenas ondas secundárias que irão

produzir uma nova frente de onda na direção de propagação. Essa propagação da

frente de onda pode ser representada usando vetores assim como na ilustração da

esquerda da Figura 3.Cada posição da frente de onda tem uma componente

eletromagnética que aponta para o receptor.

8

Figura 3 – Estudo do princípio de Hyugens

O uso de ondas de rádio freqüência RF para construir uma rede Wireless é o

suficiente para o bom funcionamento do projeto. Essa tecnologia é com certeza capaz

de atender a todas as necessidades do sistema de comunicação do ‘Restaurante

Wireless’.

2.2. Teoria de Sotftware

2.2.1. Banco de dados relacional

Como o próprio nome já diz, um banco de dados relacional é um conjunto de

dados armazenados e organizados de forma com que todos os dados se relacionem

entre si buscando uma não redundância do banco. Exemplos primitivos de banco de

dados seriam as listas telefônicas e fichas de um acervo de biblioteca.

O maior objetivo de um banco de dados é proporcionar um ambiente adequado

e eficiente para uso na recuperação e armazenamento de informações.

Existem apenas quatro operações típicas e possíveis em um banco de dados:

inclusão, exclusão, alteração e consulta. Para a melhor manipulação de um banco de

dados, existem sistemas gerenciadores, mais conhecidos como SGBD (Sistemas

Gerenciadores de Banco de Dados).

Dentro de um bando de dados podemos encontrar algumas estruturas típicas

de um banco de dados relacional, apresentadas na Tabela 2:

Nome da estrutura Descrição Tabelas Estrutura criada para armazenar os dados propriamente ditos.

Suas colunas chamam-se campos e suas linhas chamam-se registros.

Visões Tabelas virtuais criadas a partir das tabelas físicas existentes no banco de dados. As Views geralmente são uma simples consulta no banco de dados onde o resultado da consulta é a própria tabela virtual.

Procedures Procedimentos padrões criados nos bancos de dados para fazer

9

suas devidas atualizações e modificações. Geralmente torna-se procedure uma manipulação bastante freqüente que ocorre no banco ou quando são operações que se tornam inviáveis de trabalhar na própria linguagem de consulta do banco.

Exceções São as exceções que são previstas que ocorram quando da manipulação do banco de dados. São levantadas e geradas pelo próprio administrador do banco ao criar uma procedure, por exemplo.

Chaves Responsáveis pela consistência do banco, pois são elas que criam os relacionamentos entre tabelas e também não permitem que determinado dado jamais se repita dentro de uma mesma tabela. Existem dois tipos básicos de chaves:

• Chave primária: responsável pela unicidade de um campo em uma tabela. Pode ser simples ou composta por um ou mais campos.

• Chave estrangeira: criada para manter o relacionamento entre duas e/ou mais tabelas.

Funções Criadas para auxiliar a manipulação do banco de dados, podendo ser invocada de dentro de uma procedure, trigger, view ou uma simples consulta no banco.

Generators Geralmente usados para criar campos de auto-numeração Triggers São funções que se ativam quando ocorre uma determinada

operação de manipulação dentro de uma tabela específica. Estas muitas vezes chegam até a fazer modificações em outras tabelas. São classificadas em quatro tipos básicos:

• Before Insert: antes de uma inserção • Before update: antes de uma atualização • After insert: depois de uma inserção • After update: depois de uma atualização

Indices Criados para ajudar a agilizar todo o processo de consulta e/ou ordenação dos dados das tabelas.

Tabela 2 – Estrutura do banco de dados

A linguagem mais utilizada para realizar todas as operações básicas em banco

de dados é o SQL, que varia em sua concepção de SGBD para SGBD, mas em suma

ela é bastante parecida em todos eles. O SQL é uma linguagem extremamente

simples que possui uma eficiência muito grande em suas consultas. A Figura 4

exemplifica o modelo entidade/relacionamento de uma locadora.

10

Figura 4 – Modelo ER

É importante lembrar que também existem num banco de dados os tipos de

dados dos campos de uma tabela. Portanto é possível armazenar um dado como

sendo texto (string), inteiro, real entre muitos outros dependendo também do SGBD.

Assim é possível fazer operações em banco normalmente, pois trabalhar com os tipos

de dados é bastante simples.

O uso de banco de dados no projeto está relacionado ao cadastro de clientes

do restaurante e também aos pedidos por eles realizados.

11

2.2.2. Protocolos de comunicação

Seria extremamente difícil e com certeza é possível dizer que praticamente

impossível, conseguir um sistema de comunicações com alto grau de fidelidade sem

que exista um protocolo de comunicação. O protocolo de comunicação é responsável

por toda a regra da transmissão das informações no meio. Sem um protocolo de

comunicação, as mensagens com certeza se perderiam. Sem mencionar que todos

que pudessem receber, poderiam facilmente saber do que se trata a mensagem em

questão.

Um protocolo de comunicação define parâmetros importantes na comunicação,

tais como:

• Endereço de origem.

• Endereço de destino.

• Conteúdo dos dados.

• Tamanho da mensagem.

• Verificação de erros.

• Etc.

Dentre outros inúmeros parâmetros que poderiam fazer parte de um protocolo

de comunicação, esses são com certeza o básico para quaisquer protocolos. A figura

5 mostra um exemplo básico de estrutura de um protocolo.

Figura 5 – Exemplo de estrutura de um protocolo

Um protocolo define como será realizada a comunicação entre duas estações

quaisquer. É a partir do protocolo que uma estação sabe se uma determinada

mensagem é ou não destinada a ela. Existem dezenas de protocolos em uso hoje, que

atendem a determinados tipos de comunicação. Dentre tantos protocolos, alguns

bastante famosos estão listados abaixo:

• TCP/IP – Protocolo de internet.

• UDP – Protocolo de transporte para internet.

• FTP – Protocolo para transferência de arquivos.

• SMTP – Protocolo de serviços de e-mail.

12

• RTP – Protocolo de transporte de dados em tempo real.

Um protocolo de comunicação para controlar a transferência de informações é

implementado em camada de software pelo desenvolvedor. O uso de protocolo no

projeto do ‘Restaurante Wireless’ é extremamente importante para manter a

integridade da troca de mensagens que existirá.

2.2.3. Linguagem C++ - Orientação a objetos

A linguagem de programação C foi desenvolvida em uma laboratório chamado

Bell Labs em meados da década de 1970. Imprevisívelmente surgiu de outra

linguagem de programação chamada ‘B’. Foi inicialmente projetada como uma

linguagem de programação de sistema para o UNIX, e acabou se expandido para

muitos outros sistemas. Assim, surgiram algumas versões da linguagem até que a

versão de Kernighan e Richie foi padronizada e conhecida como ANSI C tornando-se

dominante entre os programadores. [8]

Bjarne Stroustrup no mesmo laboratório Bell Labs, iniciou desenvolvimento da

linguagem C++ na década de 1980. C++ tem um suporte completo a orientação a

objetos, e devido a isso se tornou largamente usada.[8]

Por ser uma linguagem que facilita o acesso a posições de memória e

alocações de espaços de memória, a linguagem C++ é aconselhada para vários

programas de sistema e de hardware. E por ser considerada também a linguagem de

programação de baixo nível de mais fácil entendimento, o C/C++ possui um grau de

utilização altíssimo entre os desenvolvedores de hardware, software e firmware.[8]

Por todas essas características, o C++ é mais do que suficiente para a implementação

do projeto do sistema de ‘Restaurante Wireless’.

13

2.3. Teoria de Hardware

2.3.1. Display gráfico GLCD

Os módulos LCD são interfaces de saída muito úteis em sistemas

microprocessados. Podem ser Gráficos ou de Caracteres. Os módulos LCD gráficos

são encontrados com resoluções de 122x32, 128x64, 240x64 e 240x128 dots pixel. Os

LCD comuns (tipo caractere) são especificados em número de linhas por colunas e

são encontrados nas configurações 2 linhas x 16 caracteres, 2 linhas x 24 caracteres,

entre outros.

Os módulos LCD possuem um controlador próprio que permite a interligação

com outras placas através de seus pinos, onde o barramento de dados e de controle

deve ser interligado ao circuito do usuário. Para a comunicação com o display, deve

haver um protocolo que envolve o envio de bytes de instrução e bytes de dados pelo

sistema do usuário.

Os módulos de LCD são projetados para funcionarem com a maioria das

CPU’s do mercado, atendendo apenas a restrições de clock para leitura/escrita. No

GLCD existe a CGRAM, que é a região da memória RAM destinada à criação de

caracteres especiais.

Para a inicialização dos módulos é necessário executar um procedimento que

se resume em enviar uma seqüência de instruções para configurar o modo de

operação para a execução de um dado programa de interfaceamento.

Figura 6 – Ilustração de um GLCD

O uso de um GLCD no projeto é imprescindível devido à interação que o cliente

do restaurante deve ter com o sistema no momento em que estiver sentado à mesa

para fazer o seu pedido. A figura 6 mostra o exemplo de um GLCD.

14

2.3.2. Transceiver

Transceiver é um circuito responsável pela comunicação existente entre duas

estações que utilizam comunicação, seja ela por infra-vermelho, bluetooth ou RF. A

palavra Transceiver já possui dois significados: ‘Trans’ que vem de transmitter e

‘ceiver’ que vem de receiver, ou seja, transmissor e receptor ao mesmo tempo.

Com essa visão geral, conclui-se facilmente que o circuito tanto envia

informações quanto recebe. Portanto, além de bastante prático é muito útil também.

Existem no mercado transceivers que são concebidos para operarem em

determinadas faixas de freqüência, isso vai depender do responsável pelo projeto

saber qual delas atende às necessidades do sistema.

Alguns destes transceivers possuem também uma interface direta para alguns

microcontroladores o que ajuda bastante a implementação do projeto. A Figura 7

mostra a foto de um transceiver.

Figura 7 – Ilustração exemplo de um Transceiver

A utilização do transceiver no projeto é bastante importante para estabelecer a

conexão entre dois pontos e fazer a troca de informações. O transceiver atende a

todas as exigências do projeto.

15

2.3.3. Microcontrolador

Um microcontrolador é um computador e como todos os computadores, ele

também possui vários fatores em comum com os demais dispositivos (por exemplo,

microprocessadores):

• Todos possuem uma CPU.

• Todos possuem no mínimo uma memória RAM para poder armazenar

variáveis.

• E todos possuem alguma interface de entrada e saída I/O.

Existe uma grande diferença entre microcontroladores e microprocessadores.

Os microprocessadores são concebidos para realizarem diversas tarefas, por isso

servem para os computadores que são largamente utilizados no mundo. Em um

computador muitos tipos de tarefas são realizadas portanto é necessário um

microprocessador que além de conseguir trabalhar com vários tipos de tarefas

diferentes, consegue fazer isso em altíssimas velocidades.

Para um microcontrolador, a velocidade não dita a eficiência do sistema, pois

um microcontrolador é usado em sistemas dedicados, ou seja, que realizam tarefas

limitadas. Geralmente os microcontroladores possuem alguma interface de

comunicação serial e algumas outras funcionalidades embutidas, dependendo do

fabricante. Isso faz com que os microcontroladores sejam extremamente utilizados em

sistemas dedicados, por exemplo, um microcoondas que possui um teclado e um

display, com certeza possui um microcontrolador. A velocidade para a aquisição dos

dados de entrada do teclado e contagem de tempo de duração não precisa ser

extremamente grande, para tanto o clock do próprio microcontrolador já é o suficiente.

Os microcontroladores assim com os processadores podem ser de dois tipos:

RISC e CISC. Aqueles que possuem uma arquitetura CISC possuem muitas

instruções (Instruction set) que são complexas em comparação com um RISC. Na

arquitetura RISC são utilizadas poucas instruções mais simples para executar uma

operação comparável e em menos tempo que uma arquitetura CISC.

Um controlador RISC básico pode ser constituído das seguintes partes:

• ULA – Unidade Lógica Aritmética (realiza operações lógicas e aritméticas).

• Banco de registradores – Registradores de uso geral.

• Multiplexadores – Auxiliam o caminho dos sinais.

• Memória RAM – Memória de dados volátil.

• Memória ROM – Memória de programa.

• Unidade de Controle – Controla o valor de todos os pinos de controle do

sistema.

16

• Unidade de busca da próxima instrução – Controla o PC (Program Counter).

• Barramento de dados – Contém os dados que trafegam entre os blocos.

• Barramento de controle – Contém o valor dos pinos de controle. Por exemplo,

operação a ser realizada pela ULA.

Figura 8 – Arquitetura interna de um processador RISC

Levando em consideração que o sistema terá uma interface com o usuário

através de um display gráfico e de um teclado, por onde ocorrerá a entrada de dados

pelo usuário e também que o sistema lidará com os dados em trânsito transmitidos

pelos componentes RF, é imprescindível o uso de um microcontrolador no projeto. A

figura 8 mostra um esquema básico de arquitetura interna de um processador RISC.

17

3. Especificação

3.1. Especificação do hardware

O sistema é constituído de duas partes essenciais: cliente e servidor.

O servidor controla diversos clientes basicamente. O esquema básico do

projeto é apresentado na figura 9:

Figura 9 – Esquema básico do projeto

A ilustração da esquerda representa o sistema cliente que possui os seguintes

dispositivos:

• Teclado.

• GLCD.

• Módulo Transceiver.

• Microcontrolador.

Já a ilustração do lado direito da figura representa o sistema servidor,

constituído das seguintes partes:

• Computador Servidor.

• Módulo de interface serial.

• Microcontrolador.

• Módulo Transceiver.

Dessa maneira conseguimos facilmente listar todos os módulos que serão

usados no projeto. A seguir todos os componentes a serem utilizados estão

especificados.

18

3.1.1. Teclado

O teclado a ser usado durante o projeto, servirá para ser instalado nas mesas e

fará a interface com o usuário. Onde este fará a entrada de dados dos pedidos e

enviará para a cozinha.

O teclado é um simples teclado de membrana. A figura 10 mostra um simples

teclado de membrana em corte lateral:

Figura 10 – Teclado de membrana / corte

Na figura os números 7 e 8 são respectivamente o circuito tátil ou seja aquele

que sensível ao toque dos dedos e contato com a tinta condutora que é aquele ao qual

ativa o circuito inferior representado pelo numero 4 na figura. A informação é então

conduzida pelo rabicho (número 5) até o conector(número 6).

3.1.2. GLCD

O display gráfico a ser utilizado no sistema é o KS-0108, cujo fabricante é a

Samsung. O KS-0108 é um driver de LCD do tipo LSI (Large Scale of Integration), com

64 canais de saída por ponto do sistema de matriz do LCD. Algumas outras

características do dispositivo estão listadas abaixo:

• Sinal de entrada de 8bits paralelo.

• Os dados são armazenados na RAM do display.

• Tensão de alimentação: +5V +/-10%

• Possui módulos em 128x64 e 128x32.

• Backlight.

19

• Controle de tensão do contraste (Vee).

O display é dividido logicamente ao meio, contendo dois controladores, chamados

Controller#1 e do Controller#2, onde cada um é controlado independentemente.

Cada metade consiste em 8 páginas horizontais que são 8 bits (1 byte) em nível lógico

alto. Os endereços da página, 0-7, especificam uma das 8 páginas. A figura 11 mostra

o exemplo.

Figura 11 – Esquema para uso do Display

• Endereço de Y (0-63): O contador de endereço de Y designa o endereço do

DDRAM interno. Um endereço é ajustado pela instrução e aumentado por 1

automaticamente pelo WR ou RD.

• Endereço X (0-7): Este é o endereço da página e não tem nenhuma função da

contagem.

• Display Start Line (0-63): O registro de linha do começo da display especifica a

linha na RAM que corresponde à linha superior do painel do LCD, ao indicar

índices na RAM dos dados da exposição no painel do LCD. É usado para o

deslocamento da tela.

20

3.1.3. Módulo Transceiver

O módulo transceiver a ser utilizado no sistema é o DP-1201 da Xemics. Como

já citado anteriormente, ele é ao mesmo tempo transmissor e receptor de dados por

rádio freqüência. Suas principais características são:

• É um modulo relativamente pequeno.

• Alimentação de 2,4V – 3,6V.

• Potencia máxima na saída de 11dBm.

• Receptor sensível à –111dBm.

• Alta taxa de dados >152kbps.

• Consumo de corrente: 62mA para o transmissor e 14mA para o receptor.

O módulo transceiver DP-1201 é destinado a algumas aplicações típicas, tais

como:

• Automação residencial e controle de acesso.

• Controle de processo e construção.

O DP-1201 é um transceiver que utiliza informação digital para a transmissão

dos dados à distâncias maiores que quinhentos (500m) metros em locais abertos. O

módulo já incorpora uma antena através de dois pinos externos (TX e RX). O

diagrama de blocos do DP-1201 é mostrado na figura 12.

Figura 12 – Diagrama em blocos do módulo Transceiver

21

3.1.4. Microcontrolador

O microcontrolador utilizado no projeto é um controlador que possui uma

arquitetura básica para alguns fabricantes tais como: Atmel Corp. ,Siemens, Intel,

chamado 8051, que é um microcontrolador de 8 bits otimizado para aplicações de

controle. Este uC possui :

• CPU de 8-bits otimizada para aplicações de controle

• Processamento Booleano Amplo (lógica Single-bit)

• Espaço de endereçamento de Memória de Programa de 64K

• Espaço de endereçamento de Memória de Dados de 64K

• 4K bytes de Memória de Programa on-chip

• 128 bytes de RAM de Dados on-chip

• 32 linhas de I/O programáveis

• Dois contadores/timer de 16-bits

• UART Full duplex

• Estrutura de interrupção com dois níveis de prioridade

• Oscilador de relógio On-chip

Quanto à memória o ‘8051’ possui 4kB de memória de programa interno

(ROM), podendo-se ainda utilizar 64kB externos. Possui RAM interna, e possibilidade

de RAM externa. As memórias de programa e de instrução, têm endereçamento

distintos, sendo identificada qual memória deve ser acessada por utilizar-se de

instruções distintas. Mapeia em memória registradores, portas de I/O, ponteiros do

sistema, temporizadores. Os endereços de 0x00 a 0x20 são 4 bancos de registradores

com 8 registradores cada. Os endereços de 0x21 a 0x30 podem ser endereçados bit a

bit ou byte a byte. O pino PSEN é elevado a 1 para acessos a memória interna,

ficando em 0 em acessos a memória externa. O sinal ALE é utilizado para enviar o

endereço a ser acessado na memória externa a um latch. Esse endereço vem do

registrador DPTR.�

Quanto as capacidades de entrada e saída, A família 8051 possui as seguintes

capacidades de I/O “nativas”, variáveis conforme o modelo:

• 32 Portas de I/O endereçáveis individualmente, divididas em 4 portas de 8 bits

mapeadas em RAM com bits individualmente endereçáveis (58 ou 24 portas

dependendo do modelo)

• 1 UART Full-Duplex

• Modelos com 4 ou 8 Canais A/D

• Modelos com 10 ou 5 Canais PCA�

22

A Figura 13 a seguir ilustra a pinagem do dispositivo da família 8051:

Figura 13 - Pinagem do microcontrolador 8051

3.1.5. Computador Servidor

Para o servidor um computador qualquer pode ser utilizado, lembrando apenas

que os drivers para a utilização do banco de dados e da serial sejam instalados na

máquina.

23

3.2. Especificação do software

A camada de software do projeto pode ser divida em três partes:

• Programa da ROM para os microcontroladores clientes.

• Programa da ROM para o microcontrolador do servidor.

• Software instalado no Servidor que faz interface com o banco de dados.

O programa da ROM dos microcontroladores clientes possui a funcionalidade de

fazer a interface com o usuário através do teclado e do display gráfico. É responsável

também pela montagem do pacote que deve ser enviado pelo transceiver assim como

o controle de quantos ‘frames’ foram e/ou devem ser enviados.

O programa gravado na ROM do servidor é responsável pelo tramite das

informações na rede, é ele que será responsável pelo envio e recebimento de

requisições enviando informações do servidor assim como recebendo pedidos de

clientes. É responsável pelo controle de tráfego de dados na rede, controle de

colisões, esquemas de endereçamento e controle de requisições de mensagens.

Quanto ao software, este será instalado no computador do servidor terá

comunicação direta com o banco de dados e conterá informações sobre cadastro de

clientes e funcionários-usuários do sistema. As figuras 14 e 15 ilustram as telas do

sistema.

Figura 14 – Tela de login do sistema

24

Figura 15 – Tela principal do sistema

3.2.1. Banco de dados

O SGBD a ser utilizado pelo sistema é o FIREBIRD, compatível com o

INTERBASE que é nativo dos compiladores da Borland, este SGBD fornece senão

todas, a maioria das funcionalidades que um banco de dados deve possuir. Com

dezenas de aplicações que auxiliam o trabalho com o SGBD, a simplicidade de se

trabalhar com o gerenciador e ainda com a vantagem de que os compiladores da

Borland são totalmente compatíveis com ele, fica extremamente simples utilizá-lo no

projeto.

3.2.2. Protocolo de comunicação Wireless

Existem protocolos alvo para o projeto, porém, o protocolo do projeto não

seguirá à risca nenhum deles, tentará apenas incorporar algumas funcionalidades. Um

dos protocolos em questão é o CSMA/CA.

Para assegurar que os meios de transmissão sejam corretamente compartilhados, as

redes sem-fio usam um esquema conhecido como ‘Carrier Sense Multiple Access with

25

Collision Avoidance’ (CSMA/CA). Ao invés de depender de todas as outras estações

para receber todas as transmissões, o CSMA/CA ativa uma breve transmissão do

receptor pretendido antes de transmitir um pacote. Colisões de mensagens de controle

podem acontecer quando se estiver usando o CSMA/CA, porém podem ser tratadas

facilmente.

Quando uma colisão acontece, as estações implementam o que é chamado de

backoff, onde são dados tempos aleatórios antes de reenviar as mensagens de

controle. Considerando que o tamanho do pacote da mensagem de controle é muito

pequeno, a probabilidade de uma nova colisão é extremamente pequena. [Comer,

Douglas E.]

A idéia inicial do protocolo a ser realmente implementada é de que o servidor

controla todas as estações. Ao invés de uma estação simplesmente mandar seu

pedido em um tempo aleatório para o servidor correndo assim o risco de uma colisão,

é o servidor quem vai perguntar para a estação se existe algum pedido a ser feito. E

assim ficará em loop infinito por todas as estações clientes sempre fazendo a mesma

pergunta até que encontre alguém com alguma requisição. Ao encontrar, a troca de

informações é realizada normalmente até seu término, depois disso o servidor retorna

a sua atividade de varredura pela rede em busca de alguma estação com requisições.

No caso de mensagens enviadas pelo servidor e que se perderam, então existirá um

time-out, se não receber nenhuma resposta o servidor reenvia então o pacote, caso

não receba resposta nenhuma o servidor continua a varredura para o próximo

endereço. No caso de perda do pacote por parte do cliente, sua requisição esperará a

próxima iteração do laço do servidor.

Assim o problema de colisões é totalmente contornado e controlado. Existe

apenas o problema de perdas de pacotes e que deve ter um tratamento mais

especifico.

Considerando que o transceiver a ser utilizado envia 8bits de cada vez, pode-se

implementar um protocolo de 256bytes, divididos da seguinte forma:

• Três bytes para indicar o início do pacote.

• Um byte de endereço de origem.

• Um byte de endereço de destino.

• Um byte de CRC.

• Duzentos de trinta e um bytes de dados.

• Um byte de tipos de requisição.

• Um byte para o número seqüencial.

• Um byte para indicar o fim de pacote.

26

3.2.3. Estimativa de Custos Para o Projeto

As tabelas 3 e 4 apresentam uma estimativa do total de custos para a

implementação do projeto separado em duas partes: cliente e servidor:

Estimativa de Custos Para o Cliente

Recurso Qtde. Valor / unidade (R$) Total (R$)

Placa padrão para o microcontrolador 8051 1 10,00 10,00 Resistores 7 0,30 2,10

Capacitores 9 0,60 5,40 Diodos 3 0,20 0,60

Transistores 2 1,00 2,00 LED Vermelho 1 0,20 0,20

XTAL – 11,0592Mhz 1 4,00 4,00 8051 1 11,00 11,00

Soquetes 5 0,50 2,50 27256 ROM 1 4,50 4,50 62256 RAM 1 3,00 3,00

GLCD 1 75,00 75,00 Teclado de Membrana 1 5,00 5,00

Módulo Transceiver 1 45,00 45,00 Total 170,30

Tabela 3 – Estimativa de custo do cliente

Estimativa de Custo Para o Servidor

Recurso Qtde. Valor / unidade (R$) Total (R$)

Placa padrão para o microcontrolador 8051 1 10,00 10,00 Resistores 7 0,30 2,10

Capacitores 9 0,60 5,40 Diodos 3 0,20 0,60

Transistores 2 1,00 2,00 LED Vermelho 1 0,20 0,20

XTAL – 11,0592Mhz 1 4,00 4,00 8051 1 11,00 11,00

Soquetes 5 0,50 2,50 27256 ROM 1 4,50 4,50 62256 RAM 1 3,00 3,00

Computador PC (Config. mínimas) 1 1.400,00 1.400,00 Módulo Transceiver 1 45,00 45,00

Total 1.510,30

Tabela 4 – Estimativa de custo do servidor

27

Estima-se também que o valor da hora de trabalho seja de R$10,00. Contando

com um total aproximado de 650horas de trabalho, estima-se um custo de R$6.500,00

de mão-de-obra.

Logicamente que o total para a implementação, depende do número de clientes

a serem implementados. A equação 1 apresenta uma fórmula para o cálculo do custo.

Custo = 170,30x + 8.035,30 (Eq. 1)

,onde:

‘x’ corresponde ao número de clientes a serem implementados.

28

4. Projeto

4.1. Projeto de Hardware

O projeto de hardware possui os seguintes módulos apresentados na tabela 5:

Nome do módulo Uso

Teclado Cliente

Display Cliente

Transceiver Cliente e servidor

Microcontrolador Cliente e servidor

Tabela 5 – Módulos do hardware

4.1.1. Módulo Teclado

O Anexo 1 representa o diagrama esquemático para o módulo do teclado. A

tabela 6 representa os sinais do módulo.

Sinal Direção Tipo Tamanho Ativo em Comentários D Saída Barramento 8 bits Contato Barramento do teclado. É

ligado no port P0 do do 8051 e mapeado em memória com os dados do display.

Tabela 6 – Sinais referentes ao módulo (Teclado).

4.1.2. Módulo Display

O Anexo 2 representa o diagrama esquemático para o módulo display. A

tabela 7 representa os sinais do módulo.

Sinal Direção Tipo Tamanho Ativo em Comentários A Entrada Barramento 8 bits Qualquer

sinal Barramento de dados do display. É ligado no port P0 do do 8051 e mapeado em memória com os dados do teclado.

Tabela 7 – Sinais referentes ao módulo (Display).

29

4.1.3. Módulo Transceiver

O Anexo 3 representa o diagrama esquemático para o módulo transceiver. A

tabela 8 representa os sinais do módulo.

Sinal Direção Tipo Tamanho Ativo em Comentários TX Saída Sinal 1 bit - Transmissor do transceiver RX Entrada Sinal 1 bit - Receptor do transceiver

Tabela 8 – Sinais referentes ao módulo (Transceiver).

TX é o sinal do transceiver responsável por transmitir os dados. RX é o sinal

responsável pela recepção dos dados captados pela antena do transceiver. Quando o

transceiver está configurado em modo de recepção um clock de recepção é gerado.

4.1.4. Módulo Microcontrolador

O Anexo 4 representa o diagrama esquemático para o módulo do

microcontrolador. A tabela 9 representa os sinais do módulo.

Sinal Direção Tipo Tamanho Descrição TX Saída Sinal 1 bit Transmissor da serial RX Entrada Sinal 1 bit Receptor da serial AD Entrada Barramento 8 bits Barramento de dados e

endereço (mapeamento em memória)

A Saída Barramento 16 bits Sinais de endereçamento B Entrada Barramento 2 bits Sinais ALE(AddressLatch

Enable) e PSEN (Program Store Enable).

INT Entrada Barramento 2 bits Sinais de interrupção T Entrada Barramento 2 bits Sinais de Timers

(contadores) D Entrada Barramento 8 bits Sinais de dados

Tabela 9 – Sinais referentes ao módulo (Display).

O Anexo 5 representa o circuito responsável por fazer o mapeamento em

memória tanto do display quanto do teclado. Representa também o circuito de

interface com o transceiver. Todo esse circuito representado pelo Anexo 5 foi feito em

uma única placa de circuito impresso.

30

4.1.5. Lista de Materiais

A tabela 10 relaciona os componentes utilizados no projeto de uma forma geral.

Componente

Resistores (Diversas ordens)

Capacitores (Diversas ordens)

Diodos

LED

Microcontrolador 8051

Latch 74ls373

Memória RAM – 62256

Memória ROM – 27256

Cristais (Diversas ordens)

Chaves ON/OFF

Conectores

Placas PCI

Display KS-0108

Teclados de membrana

Transceiver DP-1201

Transistores (Diversas ordens)

Buffers 74ls244 / 74hc245

Tabela 10 – Lista de componentes

31

4.2. Projeto do Software

O software do servidor corresponderá as seguintes especificações.

4.2.1. Casos de uso

Figura 16 - Diagrama de casos de uso.

A figura 16 apresenta os casos de uso do sistema. O ator de nome cliente, não

acessa o sistema diretamente. No caso deste ator, seu cadastro e seus pedidos são

feitos remotamente através da mesa onde o cliente está sentado.

32

4.2.2. Diagrama de Classes

Figura 17a – Diagrama de classes do sistema (classes de negócio).

33

Figura 17b – Diagrama de classes do sistema (classes de brokers).

Os diagramas de classes representado nas figuras 17a e 17b acima

correspondem apenas ao diagrama das classes de negócio e brokers. Os formulários

que possuem suas próprias classes foram omitidos deste diagrama. Este diagrama

apenas representa o problema a ser tratado, são apenas as classes de negócio que

serão utilizadas pelo sistema.

34

4.2.3. Diagramas de seqüência

A seguir serão apresentados os diagramas de seqüência correspondentes às

principais funcionalidades do sistema. Da Figura 18 à Figura 21, os diagramas

correspondem ao caso de uso ‘Cadastrar Prato’. Os outros casos de uso de cadastro

funcionam da mesma maneira, por este motivo foram omitidos, com a diferença é

lógico dos parâmetros a serem passados e das janelas de cadastro. No diagrama de

seqüências de gerencia do restaurante também foram omitidos outras seqüências de

geração de relatório pois são iguais a seqüência de geração de relatório existente no

diagrama representado pela Figura 22.

Figura 18 – Diagrama de seqüência (Incluir prato).

Figura 19 – Diagrama de seqüência (Pesquisar prato).

35

Figura 20 – Diagrama de seqüência (Atualizar prato).

Figura 21 – Diagrama de seqüência (Excluir prato).

Figura 22 – Diagrama de seqüência (Gerenciar Restaurante).

36

4.2.4. Banco de dados

A persistência dos dados em um banco de dados considera o modelo entidade

relacionamento representado pela figura 23.

Figura 23 –Modelo entidade relacionamento

A seguir estão representados nas tabelas 11 a 30, o dicionário de dados do

banco de dados em questão.

Nome Descrição TB_CLIENTES Tabela que contém os dados dos cadastros de clientes. TB_CONTA Tabela que contém os dados da conta de um cliente. TB_FUNCIONARIOS Tabela que contém os dados dos cadastros de funcionários. TB_HISTORICO_PEDIDOS Tabela que contém o histórico de pedidos dos clientes. TB_INGREDIENTES Tabela que relaciona os ingredientes do restaurante. TB_LOG_MENSAGENS Tabela que armazena um ‘log’ da troca de protocolos entre mesas e servidor. TB_MESAS Tabela que contém os dados relacionados a uma determinada mesa. TB_PEDIDOS_PENDENTES Tabela que armazena os dados de um pedido que ainda não foi atendido. TB_PRATOS Tabela que armazena todos os pratos oferecidos pela casa. TB_TIPO_CARDAPIO Tabela que relaciona os tipos de cardápio existentes. TB_TIPO_ORIGEM_MSG Tabela que contém os dados que diferenciam a origem de uma mensagem. TB_TIPO_PAGAMENTO Tabela que armazena a forma de pagamento escolhida pelo cliente. TB_TIPO_PRATO Tabela que relaciona um prato aos seus ingredientes.

37

TB_TIPO_REQUISICAO Tabela que armazena os tipos de requisições usados nas mensagens. TB_TIPO_SERVICO Tabela que armazena a forma com a qual o restaurante está operando. TB_PEDIDO_CONTA Tabela que armazena as mesas que pediram a conta. TB_PEDIDO_PRATO Tabela que relaciona os pratos de um pedido.

TB_SATISFACAO Tabela que armazena se existe uma mesa que está satisfeita no tipo de operação = Rodízio

TB_TIPO_ENCERRADO Tabela que armazena os tipo de encerramento de um pedido/conta

Tabela 11 – Relação de tabelas do banco de dados

TB_CLIENTES Nome do campo Tipo Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária. NOME Texto N N Armazena o nome do cliente. USUARIO Texto N N Armazena o nome de usuário para ‘login’ do cliente. SENHA Texto N N Armazena a senha de acesso ao sistema. CPF Texto N N Armazena o CPF do usuário.

Tabela 12 – Descrição da tabela TB_CLIENTES

TB_CONTA Nome do campo Tipo Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária. VALOR_TOTAL Real N N Armazena o valor total do pedido. DTHR_ENTRADA Data N N Armazena a data de inicio dos pedidos.

DTHR_SAIDA Data N N Armazena a data de encerramento dos pedidos.

COD_CLIENTE Inteiro N N Relaciona o cliente com a conta. COD_PEDIDO Inteiro N N Relaciona o pedido com a conta. COD_TIPO_PAGAMENTO Inteiro N N Relaciona a forma de pagamento do pedido. COD_TIPO_ENCERRADO Inteiro N N Diz se a conta já foi ou não encerrada.

Tabela 13 – Descrição da tabela TB_CONTA

TB_FUNCIONARIOS Nome do campo Tipo Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária. NOME Texto N N Armazena o nome do funcionário.

USUARIO Texto N N Armazena o nome de usuário para ‘login’ do funcionário

SENHA Texto N N Armazena a senha de acesso ao sistema. CPF Texto N N Armazena o CPF do funcionário na base.

Tabela 14 – Descrição da tabela TB_FUNCIONARIOS

38

TB_HISTORICO_PEDIDOS Nome do campo Tipo Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária. COD_CLIENTE Inteiro S N Relaciona o cliente ao pedido. COD_FUNCIONARIO Inteiro N N Relaciona o funcionário ao pedido do cliente. COD_MESA Inteiro N N Relaciona o código da mesa do cliente. COD_CONTA Inteiro N S Relaciona o código da conta do pedido. OBSERVACOES Texto S N Armazena observações gerais do pedido.

Tabela 15 – Descrição da tabela TB_HISTORICO_PEDIDOS

TB_INGREDIENTES Nome do campo Tipo Nullable Chave Primária Comentários CODIGO Inteiro N S Código de chave primária. DESCRICAO Texto N N Armazena a descrição do ingrediente em questão. PRECO Texto N N Armazena o preço do ingrediente.

Tabela 16 – Descrição da tabela TB_INGREDIENTES

TB_LOG_MENSAGENS Nome do campo Tipo Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária. PACOTE Texto N N Contém o pacote completo do protocolo COD_ENCERRADO Inteiro N N Verifica se o pacote já foi tratado COD_TIPO_ORIGEM Inteiro N N Armazena o endereço de origem do pacote. CRC Texto N N Armazena o crc do pacote.

Tabela 17 – Descrição da tabela TB_LOG_MENSAGENS

TB_MESAS Nome do campo Tipo Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária. NOME Texto N N Armazena o nome da mesa. ENDERECO_HW Texto N N Armazena o endereço de ‘hardware’ da mesa. N_PESSOAS Inteiro N N Armazena quantas pessoas a mesa suporta.

Tabela 18 – Descrição da tabela TB_MESAS

TB_PEDIDOS_PENDENTES Nome do campo Tipo Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária COD_CLIENTE Inteiro S N Relaciona o cliente ao pedido. COD_FUNCIONARIO Inteiro N N Relaciona o funcionário ao pedido do cliente. COD_MESA Inteiro N N Relaciona o código da mesa do cliente. COD_CONTA Inteiro N S Relaciona o código da conta do pedido. OBSERVACOES Texto S N Armazena observações gerais do pedido.

COD_PEDIDO Inteiro N N Relaciona o pedido pendente ao histórico de pedidos da mesa.

Tabela 19 – Descrição da tabela TB_PEDIDOS_PENDENTES

39

TB_PRATOS Nome do campo Tipo Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária. NOME Texto N N Armazena o nome do prato. DESCRICAO Texto N N Armazena a descrição do prato. PRECO Real N N Armazena o preço do prato. COD_TIPO_SERVICO Inteiro N N Relaciona o prato ao tipo de serviço. PAGINA Inteiro N N Diz em qual página do cardápio o prato pertence. COD_TIPO_CARDAPIO Inteiro N N Relaciona o prato ao tipo de cardápio.

Tabela 20 – Descrição da tabela TB_PRATOS

TB_TIPO_CARDAPIO Nome do campo Tipo Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária. DESCRICAO Texto N N Armazena a descrição do tipo cardápio. (Massas, carnes..)

PAGINA Inteiro N N Armazena em qual pagina dos tipos de cardápio esse cardápio pertence.

Tabela 21 – Descrição da tabela TB_TIPO_CARDAPIO

TB_TIPO_ORIGEM_MSG Nome do campo Tipo Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária. DESCRICAO Texto N N Diz se a origem da mensagem é cliente ou servidor.

Tabela 22 – Descrição da tabela TB_TIPO_ORIGEM_MSG

TB_TIPO_PAGAMENTO Nome do campo Tipo Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária. DESCRICAO Texto N N Armazena a forma de pagamento do pedido.

Tabela 23 – Descrição da tabela TB_TIPO_PAGAMENTO

TB_TIPO_PRATO Nome do campo Tipo Nullable Chave Primária Comentários

COD_INGREDIENTE_TIPO Inteiro N S Armazena o código do ingrediente. COD_PRATO_TIPO Inteiro N S Armazena o código do prato

Tabela 24 – Descrição da tabela TB_TIPO_PRATO

TB_TIPO_REQUISICAO Nome do campo Tipo de dado Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária DESCRICAO Texto N N Armazena a descrição do tipo de requisição.

MODO_OPERACAO Inteiro N N Diz qual o modo de operação em que aquele tipo de requisição é válido.

Tabela 25 – Descrição da tabela TB_TIPO_REQUISICAO

40

TB_TIPO_SERVICO Nome do campo Tipo de dado Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária

DESCRICAO Texto N N Armazena a descrição do tipo de serviço. (A La Carte, Buffet, Rodízio).

Tabela 26 – Descrição da tabela TB_TIPO_SERVICO

TB_PEDIDO_CONTA Nome do campo Tipo de dado Nullable Chave Primária Comentários

COD_MESA Inteiro N S Código de chave primária (código da mesa) COD_CONTA Inteiro N S Código de chave primária (código da conta)

Tabela 27 – Descrição da tabela TB_PEDIDO_CONTA

TB_PEDIDO_PRATO Nome do campo Tipo de dado Nullable Chave Primária Comentários

COD_PEDIDO Inteiro N S Código de chave primária (Código do pedido) COD_PRATO Inteiro N S Código de chave primária (Código do prato) ATENDIDO Inteiro N N Diz se o pedido já foi atendido

Tabela 28 – Descrição da tabela TB_PEDIDO_PRATO

TB_SATISFACAO Nome do campo Tipo de dado Nullable Chave Primária Comentários

COD_MESA Inteiro N S Código de chave primária (Código da mesa)

Tabela 29 – Descrição da tabela TB_SATISFACAO

TB_TIPO_ENCERRADO Nome do campo Tipo de dado Nullable Chave Primária Comentários

CODIGO Inteiro N S Código de chave primária DESCRICAO Texto N N Armazena a descrição do tipo de encerramento.

Tabela 30 – Descrição da tabela TB_TIPO_ENCERRADO

41

4.3. Projeto do Firmware

Para o firmware instalado no módulo cliente (nas mesas), o programa gravado na

ROM, segue as características de funcionamento de acordo com a Figura 24.

Após inicializar todos os dispositivos (teclado, display, transceiver, variáveis

internas), então o sistema fica em loop até que alguma mensagem chegue do servidor.

Caso uma mensagem seja recebida então o protocolo é analisado e uma resposta é

enviada ao servidor, enquanto isso o sistema volta ao estado normal (loop). Enquanto

em estado normal também pode ocorrer a entrada de dados do usuário através do

teclado e então o sistema analisa os pedidos do cliente e monta um pacote que será

enviado ao servidor na próxima troca de mensagens que ocorrer.

Figura 24 – Fluxograma de funcionamento do Firmware.

O ciclo de funcionamento do firmware segue o diagrama de estados

representado pela figura 25:

42

Figura 25 – Diagrama de estados do Firmware.

Após inicializado todos os dispositivos, o sistema entra no estado ‘Aguardado

Evento’, que pode ser tanto uma entrada de dados feita pelo cliente através do

teclado, quanto uma mensagem que acabou de chegar do servidor.

No caso de o cliente fazer uma entrada de dados pelo teclado, então o sistema

entra no estado de ‘Recebendo dados de entrada’ e logo em seguida ‘Montando

protocolo’ que monta o pacote que será enviado ao servidor.

No caso de uma mensagem chegar do servidor, o sistema entra no estado de

‘Recebendo dados do servidor’ e em seguida passa para o estado de ‘Analisando Msg’

que faz a análise da mensagem que chegou do servidor. Após a mensagem ter sido

devidamente ‘entendida’ pelo sistema então este agora encontra-se no estado de

‘Enviando Msg’, após isso volta ao estado original de ‘Aguardando Evento’.

43

4.4. Projeto do Protocolo de Comunicação

Na tabela 31 é apresentado o formato do pacote de dados do protocolo definido.

Nome do campo Tamanho Descrição

Inicio 3 bytes Contém os caracteres que indicam o inicio do pacote.

End. Origem 1 byte Contém o endereço de origem do pacote

End. Destino 1 byte Contém o endereço de destino do pacote

Tipo de requisição 1 byte Contém o tipo de requisição do cliente/servidor.

Ult. Seqüencial 1 byte Número de seqüência da ultima mensagem recebida.

Dados 231 bytes Espaço reservado para os dados do pacote.

CRC 1 byte Para controle de erros na mensagem.

Fim 1 byte Caractere que indica o fim do pacote.

Tabela 31 – Descrição do protocolo de comunicação

O servidor fará o controle das mensagens fazendo uma pergunta para cada

cliente, evitando dessa forma as colisões. O transceiver utilizado no projeto necessita

de uma sincronização antes de iniciarem a troca de mensagens. O lado transmissor

precisa enviar dez vezes o caractere correspondente ao número hexadecimal 0xAA

para o lado do receptor e dessa forma poderem estabelecer o canal de comunicação.

Porém, o transceiver é instável e facilmente se perde depois de transmitir

poucos bytes de dados reais. Para solucionar esse problema o pacote de 240 bytes no

total é quebrado em pacotes menores de 30 bytes e no intervalo de envio de cada um

desses pacotes o caractere de sincronização (0xAA) é enviado mais duas vezes,

dessa forma a perda de pacotes ou pacotes que chegaram incorretos diminui

significativamente.

44

5. Resultados

Observou-se que desde a finalização do hardware do sistema bem como o

início de testes de campo efetivamente, o transceiver se mostrou muito instável com a

troca de mensagens e isso fez com que o projeto tivesse um atraso muito grande em

sua implementação até encontrar a real causa do problema.

Através de testes reais foi possível fazer um cadastro online via RF do cliente

para o servidor e, também foi possível realizar um pedido. Porém devido à

instabilidade do hardware os testes de caso eram instáveis mostrando-se funcionais

em um momento e não-funcionais em outro.

Entretanto, mesmo com os problemas encontrados pode-se observar que o

protocolo de comunicação é funcional. Pois também foi testado com cabos além de

ser testado com RF.

O software teve uma alta aceitação e com um funcionamento real muito

estável. Assim como o firmware também era estável. A troca de mensagens por RF

funcionou perfeitamente. Porém com o hardware instável devido à utilização de uma

placa de circuito impresso não roteada e nem prototipada, ficou difícil que o sistema

funcionasse em 100% dos testes. O sistema mostrou-se funcional em poucos dos

testes realizados.

Na figura 26 é possível ver a tela do software no momento em que chegou um

pedido da ‘MESA 1‘ e este foi atrelado a um dos garçons cadastrados. Esse foi um

teste realizado com sucesso.

Figura 26 – Teste funcional do sistema.

45

Na figura 27 é possível ver a mensagem sob a forma de protocolo que saiu do

firmware do cliente e chegou até o servidor sem erros de sincronia. A imagem

representa um pacote de dados que chegou perfeitamente e foi recebido no

‘hyperterminal’ do Windows.

Figura 27 – Teste de protocolo do sistema

46

6. Conclusão

Ainda é necessário um esforço para que todo o sistema implementado se torne

um produto realmente. E isso ocorrerá certamente depois de ter um hardware

reavaliado e a troca de mensagens cliente servidor ficar estável.

O sistema possui uma idéia comercialmente viável e inovadora no mercado

atual.

Considerando-se que 100% das partes funcionam perfeitamente em separado

e que poucos problemas foram encontrados no conjunto inteiro, fica evidenciado que o

esforço restante para a conclusão do projeto é pequeno porém essencial.

47

7. Referências Bibliográficas

[1] Gallo, Michael A. – Comunicação Entre Computadores e Tecnologias de Rede.

São Paulo: Thomson, 2002

[2] Tanenbaum, Andrews. – Redes de Computadores. Rio de Janeiro: Campus, 2003

[3] Comer, Douglas E. – Redes de Computadores e Internet 2� Edição. Porto Alegre:

Bookman, 2001

[4] Walker, Halliday R. – Fundamentos de Física – Eletromagnetismo. Rio de Janeiro:

LTC, 2003

[5] ATMEL CORPORATION - www.atmel.com - Consultado em 15/02/2005.

[6] XEMICS AS - www.xemics.com - Consultado em 20/02/2005.

[7] TEXAS INSTRUMENTS – www.ti.com - Consultado em 10/02/2005.

[8] http://www.cplusplus.com/doc/information/history.html - Consultado em 12/05/2005

48

8. Glossário

B

• Backoff – Quantidade aleatória de tempo que uma estação espera para

retransmissão depois de identificado um erro (Ex.: colisão).

• Bits – Unidade lógica.

• Bluetooth – Comunicação por Infravermelho.

C

• Clock – Período de tempo para o funcionamento de um dispositivo.

D

• Drivers – Sistema de interface com um hardware.

E

• Ethernet – Tipo de redes de computadores.

F

• Frame – Tamanho de um quadro para envio em um pacote dentro de uma

rede.

I

• Idle – Tempo em que um dispositivo se encontra ocioso.

L

• Latch – Circuito de lógica seqüencial cujas saídas não dependem somente das

entradas atuais, mas também de entradas anteriores.

• Loop – Laço de repetição.

P

• Plug-and-Play – Dispositivo onde ao se conectar não precisa de reinicialização

• Power-on-reset – Sistema que provoca um Reset assim que o circuito é ligado.

• Power-save – Dispositivos projetados para economizar energia.

• Power-down – Circuito que mantém as saídas de um dispositivo em alta

impedância (3-state) até que o sistema retome a tensão de operação original.

R

• Reset – Estado de incialização de um determinado sistema

S

• Standby – Tempo de ‘descanso’.

T

• Throughput – Taxa de transferência de dados. Quantidade de dados

transferida.

• Time-out – Tempo de espera para envio de um novo pacote.

49

ANEXOS

Anexo 1

50

Anexo 2

51

Anexo 3

52

Anexo 4

53

Anexo 5