SAS25 - A Meal Payment System

Transcrição

1 SAS25 - A Meal Payment System Carlos Edgar Feliciano Ramos (1), António Abreu (2) Escola Superior de Tecnologia de Setúbal Instituto Politécnico de Setúbal (1) c.edgar.ramos@gmail.com, (2) antonio.abreu@estsetubal.ips.pt Conference Topic CT 22 Resumo Este artigo apresenta um sistema inovador de pagamento de refeições em ambiente escolar, que substitui com vantagens os actuais modos de pagamento de refeições, tipicamente baseados na aquisição de senhas em papel em máquinas próprias para o efeito. Estas requerem que os alunos tenham dinheiro em espécie, o que não acontece no sistema proposto. Este aspecto é considerado tão mais importante (para encarregados de educação e estruturas de gestão das escolas) quanto mais novos são os alunos. Por outro lado, o registo electrónico das refeições servidas permite um maior controlo da utilização do refeitório, em particular, e de outras infraestruturas das escolas, em geral. O sistema proposto permite, assim, o pagamento de refeições de modo mais fiável, justo, prático e seguro. É, naturalmente, expansível ao pagamento e uso de outros serviços escolares. O sistema faz uso de cartões de identificação de aluno e funcionário com transponder (contactless card), utiliza equipamento de leitura desses cartões e aplicações informáticas, em ambiente de rede, que garantem a segurança e correcção da informação recolhida. O presente artigo apresenta também o desempenho do sistema em diferentes cenários de utilização e com diferentes equipamentos (multi-plataforma), sendo possível desta forma determinar a sua capacidade de resposta. Palavras chave: cartão de proximidade; sistema computacional embebido; RFID; rede de comunicações; RMI, threads. Abstract This article presents an innovator meal payment system in school environments. It replaces with advantages the present way how students pay for their meals, typically based in the acquisition of paper tickets in automatic machines designed for this prupose. This requires that students to have cash, which doesn t happen in the proposed system. This particular aspect is seen as more important (for parents and management school structures) as younger students are. The electronic cashier system described in this paper provides rich information about the use of the school canteen, in particular, and any another school infrastructure, in general. The system alows a more reliable, fair, practical and secure way of payment of meals. This usage can be extended to other services (payable or not) inside the school. The system requires the use of contactless identification card students and employees nowadays use in their campus, suitable reading equipment for the cards, midleware applications, and a network environment that ensure the security of collected data. The article also presents information regarding the evaluation of performance in different settings of use and with different equipments (multi-platform), allowing one to measure its response capacity. Key Words: proximity card; embedded system; RFID; communication network; RMI, threads. 1. Introdução Na maioria dos refeitórios das escolas portuguesas, o pagamento das refeições é efectuado adquirindo uma senha com dinheiro em espécie, numa máquina própria para o efeito, existindo normalmente duas tarifas diferentes: a de alunos e a de não alunos, em que a tarifa para alunos apresenta um valor mais baixo dado o estado português financiar as refeições dos mesmos. Estes sistemas têm tipicamente os seguintes problemas: Baixa fiabilidade, devido à existência de vários sistemas mecânicos, como o leitor das notas, das moedas e a impressora das senhas, que, com o desgaste ou a utilização incorrecta por parte dos utilizadores, podem dar origem a avarias.

2 Falta de trocos, que obrigam o utilizador a introduzir a quantidade de dinheiro exacta para efectuar o pagamento, caso contrário não pode adquirir a senha, trazendo grande desconforto. Impossibilidade de identificação dos utilizadores, o que permite, por exemplo, que utilizadores não alunos paguem a tarifa dos alunos, trazendo prejuízo ao refeitório. A contagem das refeições servidas é feita manualmente através das senhas, levando a divergências de quantidades de refeições servidas entre a empresa exploradora do refeitório e os serviços de acção social da escola. Aumento da insegurança decorrente do facto de se ter de transportar e manusear o dinheiro existente nas máquinas, que pode motivar assaltos. Com o intuito de combater estas lacunas, projetou-se e desenvolveu-se um sistema electrónico que permite o pagamentos das refeições no refeitório, que recorre aos actuais cartões electrónicos de aluno e funcionário (cartões de identificação de proximidade com transponder Mifare) como meio de pagamento, evitando o uso de dinheiro em espécie. O sistema pode facilmente ser expandido de modo a acomodar outras funcionalidades [7, pág. 43]. O sistema é composto por um terminal de venda (TV) colocado no final de cada linha de fornecimento de refeições, um terminal de consulta (TC) na entrada do refeitório e, possivelmente, nas diversas unidades orgânicas, e um computador servidor, todos ligados através de uma rede (Ethernet e Wi-Fi). 2. Arquitectura do sistema No projecto do sistema foram consideradas as infraestruturas de comunicação em rede disponíveis na maioria das escolas portuguesas da actualidade, de maneira a facilitar a implementação dum sistema de pagamento como o proposto. Observa-se que as redes Ethernet e Wi-Fi apresentam uma implantação generalizada, com ligação à internet. De igual modo, avaliou-se também que a existência de meios de identificação de alunos e funcionários permitam a implementação de serviços de nova geração, por exemplo, saber quais os dias em que há maior procura de refeições, quais os pratos mais procurados, etc., que fornecem informações importantes à gestão de aprovisionamentos e planeamento de operações. Hoje em dia observa-se uma penetração consistente de cartões com diversas tecnologias de identificação (código de barras, banda magnética, fotografia, e transponder RFID) nas escolas dos diversos níveis de ensino, que permitem modos de identificação considerados seguros com base nas quantias de dinheiro manipuladas pelos alunos nas escolas. A Figura 1 ilustra a arquitectura do sistema proposto, onde no espaço refeitório se visualizam dois TV e um TC, no espaço dos serviços de acção social se encontram o servidor e terminais de gestão. O sistema tem fronteiras delimitadas pelo alcance da rede de comunicação existente, que, caso esteja ligada à internet, é ubíqua. No caso particular do sistema desenvolvido e actualmente em teste, existem dois TV, um TC e um servidor ligados por uma rede Ethernet. A arquitectura do sistema assenta no modelo cliente-servidor mas não em sentido estrito. Com efeito, cada terminal tem a sua base de dados, que está parcialmente actualizada com a base de dados do servidor. Esta característica, a explicar posteriormente, permite que o sistema esteja operacional caso não hajam comunicações (falha na rede de comunicações ou falta de alimentação na rede elétrica), ou seja, os equipamentos funcionam isoladamente.

3 O terminal de gestão é responsável pela gestão da informação dos utilizadores do sistema: introdução, remoção, edição e consulta das propriedades dos utilizadores. Figura 1 - Arquitectura física do sistema de pagamento de refeições Os cartões sem contacto utilizados (Mifare 1 IC S50 [1]) possuem memória suficiente para guardar informações sobre refeições pagas mas não registadas no servidor por não haver serviço de comunicação, ou seja, quando os TV estão offline[10] Hardware O cartão de proximidade usado para identificação de alunos e funcionários utilizado em grande parte das instituições de ensino superior em Portugal segue o standard ISO14443A [2,3,4,5,6]. O alcance máximo destes cartões em situações normais é de 10cm e utilizam uma frequência de 13,56MHz. A sua memória está dividida por sectores que podem ser acedidos utilizando chaves de segurança. Os TV e TC usados são constituídos por um computador de placa única, compostos por um display gráfico colorido (LCD de 7 polegadas), um leitor de cartões de proximidade ligado por USB, uma ligação de rede Ethernet e uma pen wi-fi ligada por USB (ver Figura 2). O microprocessador é um ARM9 Cirrus EP9302 a 200MHz, implementando as vantagens da arquitectura ARM: bom desempenho, baixo consumo de energia, ocupando pouco espaço e com custo relativamente baixo Software Para o desenvolvimento do comportamento do sistema foi utilizado software livre. As plataformas escolhidas foram: Linux 2.6 da Debian como sistema operativo dos terminais de venda e de consulta. Existem versões muito estáveis para dispositivos com processador ARM. Java como linguagem de programação. Esta linguagem fornece características ímpares para o pretendido, em particular por ser orientada a objectos, ser multi-threaded, possuir garbage collector e facilita a portabilidade para sistemas operativos diferentes. SQLite como sistema gestor da base de dados. Neste produto, a base de dados é guardada num único arquivo, não necessita de dependências externas para ser

4 executado, tem um mecanismo seguro de transferências (ACID - atomic consistency isolation durability) e é multiplataforma. Figura 2 Imagem do equipamento utilizado, neste caso um terminal de venda com a pen Wifi no topo e o leitor de cartões em baixo 3. Implementação do sistema 3.1. Cloud Computing Para criar um sistema dinâmico onde a quantidade de TC, TV e servidores seja variável, recorreu-se a conceitos de computação em nuvem. A Cloud Computing usada neste sistema é do tipo PaaS (Plataform as a Service) de modelo privado[8]. Os servidores guardam a

5 informação de todos os utilizadores, estando normalmente localizados nas sedes dos Serviços de Acção Social (SAS). Os TV e TC apenas possuem a informação relativa aos utilizadores que os irão aceder. Evita-se assim que os TV e TC possuam informação replicada dos utilizadores que não os usam. A Figura 3 exemplifica uma escola que possui mais do que um refeitório. Na base de dados do servidor estão registados todos os utilizadores do sistema (A, B, C). No entanto o utilizador A não frequenta o refeitório onde se encontra o terminal 1, que neste caso regista na sua base os utilizadores frequentes (B e C). Por outro lado, os utilizadores A e B são frequentadores do refeitório onde se encontra o terminal 2, mas não o C, logo apenas os utilizadores A e B são registados na base de dados do terminal 2. Figura 3 - Esquema de armazenamento distribuído de informação Foi utilizada a infra-estrutura Java RMI[9] como meio de invocação remota entre os terminais e o servidor. Esta metodologia é baseada em objectos distribuídos, em que a aplicação cliente pode invocar os serviços fornecidos pelos objectos remotamente no servidor, reduzindo o processamento no TV ou TC, aspecto conveniente uma vez que os computadores usados tem ou podem ter recursos computacionais relativamente escassos comparativamente aos do servidor. Caso seja necessário alterar as regras de tratamento dos dados, apenas será preciso alterar o programa do servidor Estrutura do software Com vista a assegurar a escalabilidade do software a outros serviços que venham a ser incluídos no sistema, de modo a facilitar o desenvolvimento do próprio software, dado que muitas tarefas são independentes entre si, e, finalmente, para que os terminais mantenham um certo grau de reactividade na resposta dada aos eventos entretanto gerados/recebidos (ou seja, para que o excesso de actividade numa dada tarefa não bloqueia as restantes), foi utilizado multi-tasking no software implementado. A Figura 4 ilustra as threads criadas e como estas comunicam entre si. Figura 4 - Diagrama das threads

6 A descrição de cada thread é a seguinte: Thread Reader controla o leitor de cartões de proximidade. Informa a thread Main quando detecta um cartão, enviando-lhe a informação relevante sobre o utilizador. Verifica a validade da assinatura do cartão. Thread Main é responsável por efectuar a comunicação com o utilizador e gerir o tempo das restantes threads, esperando períodos máximos pelas suas respostas. Existem basicamente dois modos de funcionamento: i) responder à passagem de um cartão; ii) enviar pedidos para actualização da informação da base de dados local e mostrar imagens publicitárias no display quando não são detectados cartões. Thread Query Data Base decide sobre o sucesso da transação, i.e., se o utilizador tem direito à refeição com base na informação presente na base de dados local. O serviço desta thread é pedido pela thread Main quando não há comunicação com o servidor. Caso contrário, a decisão é tomada pelo servidor. A base de dados local é entretanto modificada e sincronizada com a do servidor logo que hajam comunicações. Thread Query RMI desencadeia o processo de estabelecimento de ligação com o servidor, incluindo o registo no servidor, envio e recepção de mensagens e sincronização da hora. Actualiza também a base de dados no servidor quando não existem utilizadores a aceder ao sistema. Para assegurar a comunicação entre as várias threads, de maneira a ser possível que estas comportem-se autonomamente, foi criada uma pilha de objectos comuns, em que um objecto possui as características necessárias para classificar um utilizador (nome, número, saldo, escola, número série do cartão, data de acesso). Este objecto é criado pela thread Reader quando um utilizador acede ao sistema, sendo classificado pela thread Query Data Base e a thread Query RMI. Figura 5 - Ilustração do fluxo de execução da aplicação quando o sistema detecta um cartão Na Figura 5 ilustra-se o fluxo de execução da aplicação no TV, que envolve as quatro threads. Resumidamente: 1. Quando o leitor RFID detecta um cartão, a thread Reader lê a assinatura e cria um objecto apenas com os parâmetros número de série do cartão e data de acesso.

7 2. As restantes threads detectam o objecto criado e iniciam os seus processos. A thread Main inicia o contador de tempo de resposta limite e informa o utilizador do início do processo. A thread Query Data Base e a thread Query RMI desencadeiam o processo de classificação do objecto encontrado. 3. Quando a thread Query Data Base e a thread Query RMI terminam os seus processos de classificação, lançam os objectos classificados para a pilha. 4. A thread Main aguarda pelo objecto classificado pela thread Query RMI, ou que o contador de tempo de resposta ultrapasse o tempo máximo definido para aguardar pela resposta do servidor. Caso exista resposta por parte do servidor, essa resposta é considerada final, caso contrário, recorre-se à resposta obtida através dos dados da base de dados local. 5. A thread Reader calcula e escreve a assinatura no cartão, e informa as restantes do sucesso da operação. 6. A thread Query RMI avisa o servidor do sucesso da operação, a thread Query Data Base regista o acesso na base de dados local e a thread Main informa o utilizador, mostrando os dados relevantes à operação (ver Figura 6). Figura 6 - Screenshot do terminal de venda Nos momentos em que o sistema não procede à classificação dos utilizadores (i.e., quando não há passagem de cartões no leitor), é realizada a actualização da base de dados no servidor com os dados registados na base de dados local. 4. Resultados e conclusão O sistema de pagamento de refeições foi integrado e testado num ambiente reduzido, com dois terminais de venda, um servidor, 10 utilizadores e usando apenas um router, tendo respondido aos requisitos propostos e previamente apresentados neste artigo. Achou-se importante e necessário avaliar o tempo de processamento de um terminal cada vez que é efectuado um pagamento de uma refeição, para verificar se o período que o utilizador tem de aguardar por uma resposta não é demasiado.

8 Foram efectuados dois testes: quando o TV tem comunicação com o servidor e quando não tem. Para um conjunto de 1000 amostras (i.e., 1000 pagamentos de refeição), foram obtidos os tempos médios presentes na tabela 1. A primeira coluna da esquerda na tabela 1 representa o valor médio, a segunda o desvio padrão dos valores da amostra e a quarta coluna refere se existe comunicação com o servidor. Tabela 1 - Tempos médios de resposta Valor Desvio Descrição Servidor (seg.) Padrão Tempo de processamento da resposta no servidor Sim Tempo de actualização do cartão após resposta do servidor Sim Tempo que o utilizador aguardou pela resposta Sim Tempo que o utilizador aguardou pela resposta Não Uma primeira observação respeita a aceitabilidade do maior dos tempos de espera. Ou seja, na pior das hipóteses, os utilizadores esperam cerca de 1.9 segundo por uma resposta do terminal de venda. Embora o tempo ideal de espera nos pareça ser 1 segundo, entendemos que uma espera média de 1.9 segundo é aceitável. De referir que no teste realizado, o tempo máximo que o utilizador aguardou pela resposta quando o sistema estava conectado ao servidor foi de segundos e de segundos quando não estava conectado ao servidor. De acordo com os valores apresentados, verifica-se que o tempo médio de resposta do TV ao utilizador é mais reduzido quando existe comunicação com o servidor, o que parece ser contraditório. Esse resultado é justificado pelo facto da thread Main ter de esperar (até um tempo máximo que é 1 segundo) pela resposta do servidor para perceber que não há comunicação. Não havendo resposta do servidor, é utilizada a base de dados local do TV. Os valores do desvio padrão são pequenos comparados com os valores da média respectivos, com excepção à primeira linha da tabela 1. Nesse sentido, atribuem valor às médias. No entanto, no caso da primeira linha, não se encontram razões de fundo que justifiquem o valor relativamente elevado do desvio padrão. No caso das experiências efectuadas, o servidor utilizado é um PC convencional com sistema operativo Windows XP Home edition. Alguma carga excessiva de processamento em outras tarefas poderá justificar o desvio padrão medido. Conclui-se assim que o sistema funciona sempre, havendo ou não comunicação. Contudo, caso não hajam comunicações, perde-se o sincronismo entre a base de dados do TV (onde se realizou a venda), a base de dados de outros TV e a do servidor. Primeiro, logo que hajam comunicações, o TV actualiza a base de dados do servidor, enviando todos os registos de vendas entretanto efectuadas. Segundo, a actualização da base de dados de outros TV é feita por intermédio do cartão (relembre-se, não havendo comunicações). O circuito integrado MF1ICS50, utilizado nos cartões Mifare, tem um espaço de memória de 1 kbyte [1]. Uma transacção (ou pagamento de refeição) é codificada no cartão usando 128 bytes. Há assim espaço para um máximo de seis refeições tomadas (256 bytes não podem ser utilizados para armazenamento dado terem outro uso) sem que hajam comunicações no ambiente escolar em causa. O estudo de qual será o método definitivo a usar para encriptação da informação de uma transacção (refeição) no cartão ainda decorre. Mas o uso de 128 bytes para cifrar a informação de uma transacção parece ser suficiente para o valor das transacções em causa. A utilização de várias threads no sistema reduziu a complexidade do desenvolvimento da solução, evitando bloqueios da aplicação quando surgiam alguns problemas inesperados e permitindo a monitorização do seu funcionamento. A divisão de tarefas em threads facilitou a

9 criação de regras de funcionamento, e como tal ajudou na estabilização do funcionamento global. O uso do RMI permitiu aligeirar os requisitos computacionais dos terminais de venda/consulta, podendo ser mais simples e por consequência mais baratos. O facto do software poder ser executado em ambientes multi-plataforma simplifica também a substituição dos componentes do sistema, não obrigando a recorrer a um único tipo de hardware ou sistema operativo. A solução responde aos requisitos inicialmente propostos, constituindo uma melhoria bastante significativa face ao sistema de senhas em papel. É um sistema com a capacidade de reduzir as dificuldades sentidas pelos funcionários dos serviços de acção social, advindas do sistema de senhas, no que diz respeito à segurança, rapidez e simplicidade. Possibilita também aos seus utilizadores um maior conforto no pagamento das refeições, bem como reduzir a zero os comportamentos fraudulentos (utilizadores não alunos desfrutam da tarifa de aluno). Tem potencialidades para poder vir a ser utilizado diariamente, faltando para isso medir-se o nível de segurança que fornece em situações de funcionamento sem comunicação com o servidor e outros terminais. Os autores agradecem o apoio dado pelos Serviços de Acção Social do Instituto Politécnico de Setúbal. Referências [1] MF1 IC S50, Functional specification, Rev. 5.2, NXP, [2] Final Committee Draft, ISO/IEC , Identification cards - Contactless integrated circuit(s) cards - Proximity cards, Part 1: Physical characteristics, ISO/IEC, [3] Final Committee Draft, ISO/IEC , Identification cards Contactless integrated circuit(s) cards Proximity cards Part 2: Radio frequency power and signal interface, Editor D. Baddeley, Motorola, ISO/IEC, [4] FINAL COMMITTEE DRAFT, ISO/IEC , Identification cards Contactless integrated circuit(s) cards Proximity cards Part 3: Initialization and anticollision, Editor D. Baddeley, Motorola, ISO/IEC, [5] Identification cards Contactless integrated circuit(s) cards Proximity cards Part 4: Transmission protocol, Editor Hauke Meyn [6] Identification cards Test methods Part 6: Proximity cards, ISO/IEC, [7] Logical Access Security: The Role of Smart Cards in Strong Authentication, Smart Card Alliance, New Jersey, EUA, [8] Platform-as-a-Service Private Cloud with Oracle Fusion Middleware, An Oracle White Paper, October [9] Paulo Sergio Almeida, Java RMI, Grupo de Sistemas Distribuídos, Departamento de Informática, Universidade do Minho [10] Moradpour Shahram, Bhuptani Manish, RFID Field Guide: Deploying Radio Frequency Identification Systems, 1a ed. Prentice Hall PTR, 2005.