Eletronica - DOMOTICA - Sistema Controle Remoto de Residências - Completíssimo, Notas de estudo de Engenharia de Produção

Baixe Eletronica - DOMOTICA - Sistema Controle Remoto de Residências - Completíssimo e outras Notas de estudo em PDF para Engenharia de Produção, somente na Docsity! PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL FACULDADE DE INFORMATICA CURSO BACHARELADO EM INFORMATICA SISTEMA INTEGRADO E MULTIPLATAFORMA PARA CONTROLE REMOTO DE RESIDÊNCIAS Alexandre Amory Prof. Fernando Gehm Moraes Juracy Petrini Júnior Orientador Trabalho final da disciplina de Trabalho de Conclusão II Porto Alegre, 4 de setembro de 2001 SISTEMA INTEGRADO E MULTIPLATAFORMA PARA CONTROLE REMOTO DE RESIDÊNCIAS Alexandre Amory Juracy Petrini Júnior Lista de Figuras FIGURA 1 — TELEAÇÃO... FIGURA 2 — BENEFÍCIOS DE DOMÓTICA.... FIGURA 3 — APLICAÇÕES POSSÍVEIS DESTE PROJETO. FIGURA 4 — ARQUITETURA DO SISTEMA...... FIGURA 5 — ESTRUTURA COMPLETA DO SERVIDOR FIGURA 6 — ESTRUTURA DA APRESENTAÇÃO ...... FIGURA 7 — ESTRUTURA INTERNA DE UM FPGA... FIGURA 8 — ESTRUTURA DE UM BLOCO LÓGICO — XILINX XC3000 FIGURA 9 — ESQUEMA DE UMA SWITCH BOX FIGURA 10 — ROTEAMENTO EM FPGA...... FIGURA 11 — EXEMPLO EM DIAGRAMA DE UMA DESCRIÇÃO ESTRUTURAL EM VHDL . FIGURA 12 — ESTRUTURA DO COMPONENTE CONT2..... FIGURA 13 — MODELO BÁSICO DE MÓDULOS PARA AUTOMAÇÃO. FIGURA 14 — ESTRUTURA INTERNA DE UM MÓDULO DE AUTOMAÇÃO INTELIGENTE. FIGURA 15 — ARQUITETURA DO PROTOCOLO EHS FIGURA 16 — ESTRUTURA DA REDE EHS .... FIGURA 17 — FORMATO DOS PACOTES EHS FIGURA 18 — FORMATO DO PACOTE BDLC. FIGURA 19 — TIPOS DE IN-FRAME RESPONSE FIGURA 20 — INTERFACE COM CPU... FIGURA 21 — GERENCIADOR DE PROTOCOLO FIGURA 22 — INTERFACE MULTIPLEXADOR. FIGURA 23 — TOPOLOGIA LÓGICA EIB..... FIGURA 24 — PacoTE EIB..... FIGURA 25 — PACOTE DO PROTOCOLO X-10 FIGURA 26 — TABELA DE COMANDO DO PROTOCOLO X-10 FIGURA 27 — MÉTODO DE DETECÇÃO DE ERROS DO PROTOCOLO X-10 FIGURA 28 — FUNÇÕES DAS CAMADAS DE CAN.... FIGURA 29 — FORMATO DE UM PACOTE DE DADOS CAN. FIGURA 30 — CAMPO DE ARBITRAÇÃO ..... FIGURA 31 — REQUISIÇÃO REMOTA DE DADOS FIGURA 32 — PACOTE DE REQUISIÇÃO DE DADOS CAN. FIGURA 33 — PACOTE DE ERRO CAN . FIGURA 34 — PROCESSO DE SINALIZAÇÃO DE ERROS FIGURA 35 — BIT STUFFING.... FIGURA 36 — ESTADOS DE ERRO . FIGURA 37 — ARBITRAÇÃO CAN FIGURA 38 — BIT TIME CAN.. FIGURA 39 — SINCRONIZAÇÃO COM TRANSMISSOR LENTO. FIGURA 40 — SINCRONIZAÇÃO COM TRANSMISSOR RÁPIDO FIGURA 41 — FORMA DA FIAÇÃO CAN. FIGURA 42 — TENSÃO NOMINAL... FIGURA 43 — INTERFERÊNCIA ELETROMAGNÉTICA FIGURA 44 — TRANSCEIVER.... FIGURA 45 — MÓDULO CAN STAND-ALONE FIGURA 46 — MÓDULO CAN INTEGRADO FIGURA 47 — MÓDULO CAN SINGLE-CHIP. FIGURA 48 — BASICCAN..... FIGURA 49 — FULLCAN.. FIGURA 50 — FILTRO SIMPLES FIGURA 51 — MÚLTIPLOS FILTROS... FIGURA 52 — ARQUITETURA GERAL DO MÓDULO CAN. FIGURA 53 — ESTRUTURA DETALHADA DO MÓDULO CAN. FIGURA 54 — DETALHE DO BLOCO DE INTERFACE COM MEMÓRIA E APLICAÇÃO DO USUÁRIO FIGURA 55 - ARQUITETURA DO SISTEMA..... FIGURA 56 — TABELAS DO SISTEMA. FIGURA 57 - TABELANODOS.... FIGURA 58 — MÉTODOS DE ACESSO A BASE DE DADOS E PORTA DE COMUNICAÇÃO R$-23' FIGURA 59 — PROBLEMA DE SEQUENCIAMENTO DE PACOTES... FIGURA 60 — LISTA DE RECEBIMENTO DE PACOTES GRANDES... FIGURA 61 — TELA DE AUTENTICAÇÃO. FIGURA 62 - INTERFACE CLIENTE... FIGURA 63 — INTERFACE DE ADMINISTRAÇÃO. FIGURA 64 — INSERINDO USUÁRIOS FIGURA 65 — ALTERANDO USUÁRIOS. FIGURA 66 — EXCLUINDO USUÁRIOS FIGURA 67 — DEBUGGER.... FIGURA 68- DISPOSIÇÃO HIERÁRQUICA DOS MÓDULOS FIGURA 69 - INTERAÇÃO ENTRE OS BLOCO DO CAN CONTROLLER. FIGURA 70 — INTERAÇÃO ENTRE OS BLOCO DO CAN CORE .. FIGURA 71 — PLATAFORMA NODO ESCRAVO (XS40) FIGURA 72 — ESQUEMA XS40..... FIGURA 73 — ARQUITETURA DO NODO DE LÂMPADAS..... FIGURA 74 — MONITORAÇÃO PELO OSCILOSCÓPIO DE UM PACOTE CAN COMPLETO FIGURA 75 “TRANSMISSOR X RECEPTOR CAN..... FIGURA 76 — SIMULAÇÃO DE UM PACOTE CAN COMPLETO ..... FIGURA 77 — COMPARAÇÃO ENTRE BARRAMENTO, BITS DO TRANSMISSOR E DO RECEPTOR. FIGURA 78 — PROCESSO DE ENVIO DE PACOTES .... FIGURA 79 — PROCESSO DE RECEPÇÃO DE PACOTES. FIGURA 80 — ARQUITETURA DO NODO MESTRE. FIGURA 81 — PLATAFORMA NODO MESTRE (VW 300) FIGURA 82 — CONVERSÃO CAN PARA SERIAL...... FIGURA 83 — CONVERSÃO SERIAL PARA CAN... FIGURA 84 — TRANSMISSÃO SERIAL DO MESTRE. FIGURA 85 — RECEPÇÃO CAN NO MESTRE COM TRANSMISSÃO SERIAL . FIGURA 86 — ESCRITA E LEITURA NA FILA CAN FIGURA 87 — ESCRITA E LEITURA DA FILA SERIAL. FIGURA 88 — ESTRUTURA DO TESTBENCH DO MESTRE. FIGURA 89 — BANCADA DE TESTE DO MESTRE... FIGURA 90 — DETALHES DA BANCADA DE TESTE. FIGURA 91 — FORMATO DE PACOTES DE DADOS. FIGURA 92 — FORMATO DE PACOTES DE CONTROLE . FIGURA 93 — INTERFACE HARDWVARE/SOFTWARE.... vi Lista de Tabelas TABELA 1 — TIPOS DE MEIOS FÍSICOS EHS.. TABELA 2 — TABELA COMPARATIVA ENTRE PROTOCOLOS . TABELA 3 — LEGENDA DA TABELA COMPARATIVA DE PROTOCOLO: TABELA 4 — COMPARATIVO ENTRE CAN PADRÃO E ESTENDIDO . TABELA 5 — CODIFICAÇÃO DO CAMPO DLC... TABELA 6 — TAXA DE TRANSFERÊNCIA X COMPRIMENTO DO BARRAMENTO TABELA 7 — COMPARAÇÃO ENTRE DIVERSAS LINGUAGENS DE PROGRAMAÇÃO. TABELA 8 — TABELA USUARIOS ..... TABELA 9 — TABELA TABELANODOS TABELA 10 - TABELA TABELADADOS..... TABELA 11 - DESCRIÇÃO DA PORT LISTDO CAN CONTROLLER. TABELA 12 — DESCRIÇÃO DA PORT LISTDO CAN INTERFACE TABELA 13 - DESCRIÇÃO DA PORT LISTDO CAN CORE TABELA 14 - DESCRIÇÃO DA PORT LISTDO CAN RX... TABELA 15 - DESCRIÇÃO DA PORT LISTDO CAN Tx TABELA 16 - DESCRIÇÃO DA PORT LISTDO CRC CALC. TABELA 17 - DESCRIÇÃO DA PORT LISTDO SYNC..... TABELA 18 - DESCRIÇÃO DA PORT LISTDO STUFF HANDLER. TABELA 19 - DESCRIÇÃO DA PORT LISTDO ERROR FRAME . TABELA 20 - DESCRIÇÃO DA PORT LISTDO ERROR COUNTER TABELA 21 — RESUMO DE DADOS DOS MÓDULOS HURRICANE TABELA 22 — RESUMO DE RELATÓRIOS DE SÍNTESE DO MESTRE...... TABELA 23 — RELATÓRIO DO TESTBENCH DO MESTRE (CAN PARA SERIAL) TABELA 24- RELATÓRIO DO TESTBENCH DO MESTRE (SERIAL PARA CAN) . Abstract The objective of this work is to implement a control system for domestic applications — domotics or smart houses. This application is controlled through the Internet, being the home devices comected using the CAN control protocol. The user remotely controls his house using a standard Web navigator. This remote application is a client program. Locally, the server translates the instructions from/to the Web navigator and distributes them to the domestic applications. 3 Nos dias de hoje, existem algumas poucas empresas no mundo que desenvolvem produtos visando domótica [2]. Na Europa, principalmente, existem vários grupos que estão trabalhando no desenvolvimento de um protocolo doméstico padrão. Esses grupos, sem exceções, estão ligados a grandes fabricantes de eletrodomésticos e produtos de uso doméstico em geral. No Brasil, não se tem notícia de empresa que desenvolva produtos para domótica, mas existem revendedoras de empresas estrangeiras. Ainda assim, são raras essas empresas, pelo fato de que produtos visando domótica não serem acessíveis financeiramente à maioria da população. 1.2 Requisitos de um Sistema de Automação Doméstica Para saber exatamente quais são as reais exigências que um sistema de automação doméstica deve ter é necessário uma equipe multidisciplinar, engenheiros, arquitetos, sociólogos, para identificarem o cenário doméstico, conforme [2]. Tal estudo terá a função de descrever a situação da domótica no futuro e definir por quais caminhos esse estudo deve seguir para alcançá-lo, no ponto de vista europeu. O resultado deste estudo foi dividido em três partes: facilidades, vantagens e exigências técnicas. Por facilidades entende-se todas as finções que o usuário gostaria de ter integrada num sistema, de modo a facilitar o seu cotidiano. Citamos as seguintes necessidades: e manutenção doméstica; * conservação e preparo de comida, preparo de roupas; e comunicação e “home office”, e entretenimento (áudio, vídeo, tv, rádio); e controle de energia, aquecimento, água, iluminação, ou ventilação; e segurança em relação a invasão, fogo, inundação, ou mau tempo. Por vantagens entende-se os beneficios! que a domótica terá que propiciar para a satisfação do usuário final. Essas necessidades e vantagens devem ser consideradas como pré-requisitos em um sistema de automação doméstica. ! benefícios serão detalhados na Seção1.3. Exigências técnicas são características que o desenvolvedor de sistema deve conhecer e saber contorná-los para implementar um sistema competitivo e com aceitação no mercado. As principais exigências são: e baixo custo (sistema de fácil instalação e dispositivos baratos); e plug and play, e flexibilidade (sistema modular e extensível); e integração com todas aplicações; e integração com vários fabricantes (padronização); e compatibilidade com vários meios (linha de energia, radio-frequência, par trançado, infra vermelho); e confiabilidade; e fácil utilização. Baixo custo para o usuário final significa, primeiramente, que a instalação da rede deve ser facil, de modo que necessite o mínimo possível de uma pessoa especializada para isso. Por outro lado, os dispositivos da rede devem ser baratos também. O usuário não vai pagar uma diferença de preço muito grande por uma lavadora de roupa conectada a rede se existe uma similar mais barata, mas que não pode ser conectada. Resumindo, o custo adicional para dispositivos de domótica devem ser extremamente baixo. Os dispositivos devem ser plug and play, pois o próprio usuário deve ser capaz de fazer instalação da rede, de novos dispositivos e de reconfigurar a rede. O ciclo de vida do sistema deve ser grande. O sistema instalado deve ser extensível. Deve ser possível integrar novos dispositivos e novas aplicações mesmo que esses ainda não existam. Isso implica que o sistema deve ser flexível a novas tecnologias. Deve ser possível integrar todas as aplicações de um sistema de domótica. Não é uma boa estratégia instalar um sistema para controle de ar condicionado, outro para segurança, e assim por diante. As aplicações estando integradas possibilitam o compartilhamento de recursos e interoperabilidade. Dispositivos de um fabricante devem ser conectados na mesma rede que dispositivos de um outro fabricante qualquer. Esta característica é a base de um sistema de automação. 5 O sistema deve ser confiável. Pelo fato do sistema integrar muitos dispositivos de diferentes características e fabricantes, aumentando-se as chances de que esse sistema se torne potencialmente sujeito a falhas. É desejável que o sistema inclua funções de monitoramento e teste, aumentando o grau de disponibilidade do mesmo. Outro ponto muito importante é a facilidade de uso. A interface deve ser intuitiva e ter formas similares de executar funções diferentes, para facilitar o aprendizado do mesmo. Levando em conta que o sistema deve tornar algumas tarefas de casa independentes de sua intervenção. 1.3 Benefícios da Domótica Os beneficios de domótica concentram-se em quatro classes: segurança, conforto, economia de energia e comunicação. Esses itens serão descritos abaixo e podem ser visualizados na Figura 2. ad Alarme O” Temperatura — conto Piscina Entretenimento Figura 2 — Benefícios de Domótica 1.3.1 Segurança Trata de proteger pessoas e pertences em casos de eventualidades como invasão, vazamento de água, vazamento de gás, incêndio, doenças, etc. Pode-se destacar como aplicações: * alarmes técnicos: inundação, gás, queda de energia; e fogo e fumaça: detecção rápida, alerta a moradores, chamada de bombeiros; INTERNET ps aço va . E did TE) Figura 3 — Aplicações possíveis deste projeto Já no caso 3, João está trabalhando quando de repente recebe uma mensagem urgente comunicando uma invasão à sua casa. Imediatamente ele se conecta à casa e, através das câmeras de segurança, consegue ver a imagem do invasor. Ao mesmo tempo que o sistema já havia enviado uma mensagem à polícia notificando a invasão. O caso 4, digamos que João e Maria decidem sair para ir ao cinema. Ao saírem da casa o sistema avisa ao PDA que esqueceram de ativar o sistema de alarme. Então, pelo próprio PDA, João aciona o sistema e verifica se todas as portas e janelas foram bem fechadas. Os quatros exemplos citados acima podem parecer muito longe da realidade atual, porém não estão. Já existem PDAs com acesso a Internet (link [15] ) e, durante a execução desse trabalho, encontramos alguns sistemas de supervisão comercial com objetivo similar ao objetivo desse trabalho (links [16] [17] [18] [19] [20] [21] ). Isso vem provar que já existem tecnologias convergindo para o objetivo deste projeto. Visamos como meta do desenvolvimento deste projeto usar tecnologia de baixo custo ou de livre distribuição de modo que uma possível comercialização do produto venha a ser viável. Durante as Seções seguintes poderá ser notado que detalhes como a linguagem de programação e o sistema operacional foram escolhidos de forma e tornar uma versão comercial deste projeto viável, visto que esta é uma motivação importante deste projeto. Outra motivação ao desenvolvimento deste trabalho foi a criação de uma nova aplicação para computadores e Internet. Pensamos que essa aplicação poderá contribuir de forma a fazer com que o uso de computadores faça cada vez mais parte do dia-a-dia do usuário comum. 9 2 Arquitetura do Sistema O sistema desenvolvido baseia-se na comunicação entre dois computadores através do protocolo de comunicação HTTP, um destes computadores é denominado de Servidor e o(s) outro(s) computador(es) denominado(s) Cliente(s). Internamente à casa existirá uma outra rede utilizando o protocolo CAN? responsável em interligar os diversos periféricos da casa. Esta rede interna, através de um Controlador Mestre, comunica-se com o computador Servidor através da porta R$-232C. A Figura 4 ilustra a estrutura geral do sistema. Controlador Mestre Cliente Servidor Figura 4 — Arquitetura do Sistema O computador Cliente é responsável por permitir que o usuário possa de maneira amigável, interagir com sua residência. Para que isso seja possível, no computador cliente, temos um sofiware responsável pelo envio de sinais de controles que neste caso iremos denominar de pacotes de controle. Estes pacotes serão recebidos pelo Servidor que se encarregará de tratá-los de maneira adequada. Devido ao crescimento e popularização da Internet no mundo, o software utilizado no lado Cliente será um navegador Web. Sendo assim, o navegador Web é responsável em enviar os pacotes de controle ao Servidor através do protocolo HTTP, e ao mesmo tempo é responsável em manter a interface com o usuário atualizada a medida que o Servidor envia atualizações. O Servidor é responsável por receber pacotes (Figura 5 - 1) de controle que serão enviados a partir do navegador Web que estiver rodando na máquina Cliente. O Servidor por sua vez ? Detalhes do protocolo CAN serão analisados no Capítulo 5 10 interpretará estes pacotes de controle recebidos do Cliente e é responsável em atualizar uma base de dados e repassar estes pacotes de controle através da porta RS-232C para o Controlador Mestre da rede interna da casa. SERVIDOR a nO qo — 3 =8|—sCume SA Apache = Ds HTML Ee CLIENTE 4 R5p32 Aplic| pe vu E V E Banco 0 Figura 5 — Estrutura completa do servidor E RE HOLINOS Para viabilizar o desenvolvimento da tarefa atribuída ao computador Servidor, utilizaremos um servidor Web Apache (link [33]), responsável em disponibilizar a interface (a partir deste momento começaremos a tratar esta interface como sendo a homepage da residência) ao(s) Cliente(s) (navegador Web). Juntamente com o servidor Web é utilizada a linguagem de programação PHP, link [28] (Figura 5 - 2) cuja responsabilidade é receber os pacotes de controles enviados pelo usuário através do navegador Web, atualizando uma base de dados (Figura 5-4) contida no servidor. Esta base de dados tem como principal função manter o estado atualizado sobre cada aplicação doméstica que está sendo controlada remotamente. Enquadra-se como responsabilidade do Servidor a atualização, de maneira transparente ao usuário, da interface do navegador Web (Cliente). Em outras palavras, isso possibilita que o usuário tenha sempre o último estado (Figura 5 - 5) sobre sua residência sem a necessidade de ficar acionando um comando de atualização da interface. Ainda no contexto do Servidor, existe uma aplicação (Figura 5 - 3) escrita em Java, responsável pela comunicação com a porta serial RS-232C possibilitando o envio de pacotes de 13 3 Definições O objetivo deste capítulo é abordar definições fundamentais que são a base deste projeto, portanto a compreensão destes conceitos é fundamental. A Seção 3.1 define o que é FPGA. A Seção 3.2 define a linguagem VHDL. Na Seção 3.3 definem-se alguns conceitos relacionados à linguagem de programação Java. 3.1 FPGA A tecnologia VLSI abriu as portas para a implementação de circuitos digitais poderosos e de baixo custo. Porém o processo de manufatura desses circuitos perdura meses. Isso resulta em um alto preço a não ser que haja produção em volumes muitos grandes. Na indústria eletrônica é vital que novos produtos alcancem o mercado o mais rápido possível, e para isso reduzir o tempo de desenvolvimento e produção é essencial. Field Programmable Gate Array (FPGA) surgiu como solução para esse problema, porque provê implementação imediata e com baixo custo de prototipação. 3.1.1 Evolução dos Dispositivos Programáveis Dispositivos programáveis são circuitos de propósito geral que podem ser configurados para uma grande variedade de aplicações. Um dos primeiros tipos de dispositivo programável foram as Programmable Read-Only Memory (PROM). As PROMS consistem de uma matriz de células que pode ser programada somente uma vez. Esse dispositivo é usado para implementar tabelas verdade. Outro dispositivo programável, específico para implementação de circuitos lógicos, é o Programmable Logic Device (PLD). Esse dispositivo é baseado em uma matriz de portas E conectada a uma matriz de portas OU. PLDs possibilitaram um grande avanço na implementação de circuitos lógicos, porém, devido a sua estrutura simples (limitação para lógica sequencial), só se podia desenvolver pequenos circuitos lógicos. O Mask Programmable Gate Arrays (MPGA) é um outro tipo de dispositivo programável que pode interconectar elementos de acordo com especificações do usuário. A maior vantagem dos 14 MPGAs sobre os PLDs é que eles possuem uma estrutura mais genérica permitindo a implementação de circuitos maiores. 3.1.2 FPGA Assim como um MPGA, um FPGA (Field Programmable Gate Array) é um circuito programável composto por um conjunto de células lógicas ou blocos lógicos alocados em forma de uma matriz [6] [7]. Em geral, a funcionalidade destes blocos assim como o seu roteamento, são configuráveis por sofiware. A Figura 7 ilustra a organização interna de um FPGA com arquitetura de roteamento baseada em canais horizontais e verticais (exemplo: Xilinx família XC4000). E Logic : E Maris Blocks Routing Blocks N 1 TII TII To TII CI vm To & db | dê || Sê |) CÊ | SÊ SÊ || GET : ES | E es es er e es e Es] |] DõãoDoõDoDãDomãi=DÕm bs | tt |) cão |) E | ts SE | ts dt do |) Sê |) SÊ |) Sês |) Sê Figura 7 — Estrutura interna de um FPGA 3.1.3 Blocos Lógicos As funções lógicas são implementadas no interior dos blocos lógicos. A arquitetura de um bloco lógico pode ser desenvolvida de várias formas e ter vários recursos. Cada fabricante e família de dispositivos pode ter uma arquitetura diferente. Porém, é importante que essa escolha vise a maior versatilidade possível. A Figura 8 apresenta a arquitetura interna de um bloco lógico de um FPGA XC 3000 fabricado pela Xilinx. 15 Em algumas arquiteturas os Blocos Lógicos possuem recursos sequenciais tais como flip- flop ou registradores. No CLB da Figura 8, por exemplo, há dois flip-flops. i dreema s Is Í | e Figura 8 — Estrutura de um bloco lógico — Xilinx XC3000 3.1.4 Roteamento Roteamento é responsável pela interconexão entre os blocos lógicos. A conexões físicas entre os fios são feitas ora com transistores de passagem controlados por bits de memória (PIP) ora com chaves de interconexão (Switch Matrix). Os recursos de roteamento da série XC4000 da Xilinx possuem: Conexões Globais: formam uma rede de interconexão em linhas e colunas de cinco fios, que se ligam através de chaves de interconexão. Esta rede circunda os blocos lógicos (CLBs) e os blocos de E/S (IOBs); Matrizes de Conexão (Switch Matrix): são chaves de interconexão que permitem o roteamento entre os canais de roteamento (Figura 9). Estas conexões são programáveis na fase de roteamento automático, executada pelo software de projeto do fabricante do FPGA. Ho iz 3 I4 4d [4 34 3 24 -2 11 ra Figura 9 — Esquema de uma Switch Box 18 crescentemente empregadas para descrever o comportamento desses sistemas digitais [3]. Essa descrição pode ser puramente comportamental, usada somente para fins de documentação e descrição funcional simulável, ou pode ser sintetizável. Para se chegar a uma descrição sintetizável são necessárias várias etapas de refinamento da descrição. Esses refinamentos visam alterações na descrição de forma a alcançarem o subconjunto de instruções HDL específicas que a ferramenta de síntese suporta. Entre os aspectos que favorecem o desenvolvimento de hardware usando HDLs podemos citar: º time-to-market - Nos tempos atuais a evolução de tecnologias estã acontecendo cada vez mais rápido. Se há dez anos atrás um produto demorava 6 meses para ser desenvolvido, mas permanecia no mercado por 2 anos, hoje um produto não permanece mais de 18 meses, logo o seu desenvolvimento deve levar bem menos tempo. Isso tem forçado o estudo de novas técnicas para diminuir o ciclo de desenvolvimento de sistemas digitais. O processo de sintese lógica automatizada ataca esse problema mecanizando etapas mais abstratas de desenvolvimento. e menor ciclo de desenvolvimento — O ciclo de desenvolvimento pode ser reduzido com o uso de VHDL, devido à eliminação de geração, manutenção de esquemáticos e pela diminuição de erros de desenvolvimento pelo uso de simulação nos ciclos iniciais do projeto; e menor custo de desenvolvimento — Diretamente ligado ao tópico anterior; e aumento de qualidade no desenvolvimento — Essa vantagem é alcançada pelo fato que VHDL facilita o rápido experimento com diferentes arquiteturas e técnicas de implementação, e pela capacidade das ferramentas de sintese otimizarem um projeto tanto para área mínima quanto para velocidade máxima; e evolução da tecnologia — Novos dispositivos surgem com mais capacidade e mais recursos internos; e gerenciamento do projeto — Projetos en VHDL são mais fáceis de serem gerenciados que os projetos baseados em esquemático. Eles facilitam a estruturação de componentes (top-down), facilitam a documentação e são necessárias menos pessoas para desenvolver e verificar, sendo também mais simples modificar o projeto; e VHDL é independente de tecnologia e fabricante, porém sabe-se que na prática não é independente de ferramenta de sintese e de simulação. 19 As desvantagens de se usar VHDL apontam, basicamente, para o aprendizado de uma metodologia nova e complexa. Citamos desvantagens tais como: e Mudança de cultura; e Aprendizado e treinamento; Escolha de uma ferramenta de desenvolvimento; e Circuito é menos otimizado que esquemático; e Ferramentas de sintese ineficientes. 3.2.1 Descrição Estrutural Um sistema digital pode ser descrito como um módulo com entradas e saídas, onde o valor das saídas é uma função dos valores de entrada. A Figura 11 (a) ilustra esse conceito, onde o módulo F possui duas entradas A e B e uma saída Y. Em VHDL o módulo F é chamado de entidade e as entradas e saídas são chamadas de portas. Um modo de descrever a função de um módulo é descrever a função de seus sub-módulos e suas conexões. Cada sub-módulo é uma instância de uma entidade, e as conexões que os conectam são chamados de sinais. A Figura 11 (b) mostra como a entidade F pode ser formada por instâncias das entidades G, H e I. Este tipo de descrição é chamada de descrição estrutural. 6) Figura 11 — Exemplo em diagrama de uma descrição estrutural em VHDL 3.2.2 Descrição Comportamental Em muitos casos não é necessário descrever a estrutura interna de um componente, uma descrição que tenha o mesmo resultado funcional é o suficiente. Esse tipo de descrição é chamada de descrição funcional ou comportamental. Para ilustrar essa idéia, suponha que a função da entidade F seja um ou exclusivo. A descrição comportamental de F poderia ser uma função como Y = A .B+A.B. 20 3.2.3 Exemplo de Descrição VHDL Nesta Seção, descreveremos um simples exemplo de um contador de dois bits. Logo abaixo está a descrição da entidade. A entidade especifica a interface externa do componente, incluindo os pinos de entrada e saída. entity cont2 is port ( clock :inbit; q1,90: out bit); end cont2; Esse trecho de programa especifica uma entidade com uma entrada e duas saídas do tipo bit que assume valores 0 ou 1. A função que um componente executa é especificada na arquitetura do componente. O trecho de programa abaixo especifica uma arquitetura comportamental para a entidade cont2. architecture comportamental of cont2 is begin count up: process (clock) variable count value : natural := O; begin if clock ='"1' and clock'event then count value := (count value + 1) mod 4; qo <= bit'val(count value mod 2); q1 <= bit'val(count value / 2); end if, end process count up; end comportamental; Dentro da arquitetura é definido um processo. Um processo é um bloco que é executado em paralelo com outros processos da mesma arquitetura. Os comandos dentro de um processo são executados sequencialmente. O processo count up é executado uma vez a cada mudança de valor no sinal de clock. O sinal clock é o ativador do processo count up. A variável count value, que é inicializada com zero, contém o valor da contagem. Uma versão estrutural que executa a mesma função que a especificada na arquitetura comportamental pode ser vista logo abaixo. Cont2 é composto por dois flip-flops e por um inversor. A Figura 12 descreve a estrutura da entidade cont2. 23 4 Protocolos de Controle A crescente demanda de comunicação, conectividade e fluxo de informações impulsionou a criação de vários protocolos de comunicação. De acordo com as áreas de aplicação para as quais os protocolos são designados, eles podem ser diferenciados. O propósito dessa Seção é mostrar as métricas usadas para escolher o protocolo a ser implementado neste trabalho. A Seção 4.1 introduz o leitor ao conceito de protocolo de controle. A Seção 4.2 apresenta características, parâmetros e requisitos de protocolos em geral. A Seção 4.3 apresenta um resumo com características principais de alguns dos protocolos estudados. A Seção 4.4 faz um resumo comparativo entre todos os protocolos estudados. 4.1 Introdução Protocolo é a especificação de um conjunto de regras em que diversos equipamentos respeitam para trocar informações. Mais especificamente, protocolos de controle são empregados, principalmente na indústria, como linguagem de comunicação entre os módulos processadores responsáveis pelo controle de atuadores e monitoração de sensores. A Figura 13 ilustra esse conceito. Dentro de cada módulo processador que está ligado no meio de comunicação deve existir um sub-módulo (P de protocolo) que contém o algoritmo da “linguagem” que os processadores entendem. Esse algoritmo é chamado de protocolo de comunicação. sensor sensor sensor atuador atuador atuador Módulo2 |... [e] Figura 13 — Modelo básico de módulos para automação 24 A área de protocolos de controle tem ganho grande importância devido ao crescimento do mercado de automação (industrial, predial, doméstica, de escritório, entre outros). Outro fator importante é a taxa de crescimento da tecnologia dos dispositivos, que tem oferecido a cada ano mais funcionalidade com menores preços. Devido a isso, o desenvolvimento de sensores e atuadores inteligentes” (Figura 14) tem sido impulsionado, exigindo a definição de padrões para os protocolos de comunicação. De um ponto de vista mais genérico, o mercado tem exigido soluções mais competitivas, que são caracterizadas por sistemas de controle altamente flexíveis às necessidades do consumidor. A chave para atingir essa meta é a padronização das interfaces de comunicação. Sensor Atuador Memória Processador o Mailbox pd Transceiver Figura 14 — Estrutura interna de um módulo de automação inteligente Quando vamos fazer uma pesquisa de protocolos de comunicação para ser implementado em algum projeto, deve-se conhecer, a priori, a aplicação alvo. Hoje em dia existem em grande número de protocolos disponíveis. Cada um destes possui características que o “protocolo do concorrente não tem” ou simplesmente para fins de proteger seu sistema e restringir o consumidor aos produtos de um único fabricante. Devido ao fato de termos muitos protocolos disponíveis, os fechados*, proprietários e não padronizados tem perdido espaço para os protocolos abertos, certificados e padronizados. Contudo, conhecer somente a aplicação do protocolo que será desenvolvido não basta, pois para uma aplicação especifica, ainda existirão dezenas de possibilidades. Algumas caracteristicas 5 Com a alta taxa de integração que, hoje em dia, dispositivos eletrônicos possuem é viável a construção de sensores e atuadores inteligentes que incorporam dentro de um único chip elementos de memória, de protocolo e de processamento para verificar limites de senscres, fazer lincarização de simais, cte. 6 sem especificação técnica do protocolo. 25 técnicas devem ser investigadas para se escolher corretamente o protocolo. A próxima Seção trata justamente disso, explicando características técnicas que devem ser estudadas. 4.2 Características e Requisitos de Protocolos O estudo das características de protocolos depende muito da aplicação destes. Por exemplo, se procurarmos por um protocolo para ser usado em uma grande indústria metalúrgica esse protocolo deve ter longo alcance para poder se estender por toda empresa, poder ligar vários nodos, ter grande imunidade a ruídos usando técnicas de detecção e correção de erros, ter alta disponibilidade e tolerância a falhas, uma vez que grandes valores e vidas humanas podem estar em jogo. Já um protocolo para aplicação de entretenimento, basicamente só usado dentro do ambiente doméstico, não necessita ter alta disponibilidade, precisa ter grande taxa de transferencia para transportar vídeo e som, um alcance curto já será o suficiente, compatibilidade entre vários fabricantes, entre outras caracteristicas. Esses dois exemplos citados acima, bem ortogonais, nos dão idéia que as características e requisitos de um protocolo podem variar muito, dependendo exclusivamente de sua aplicação. Porém, como dito na Seção anterior, conhecendo-se apenas a aplicação não se faz uma escolha adequada de protocolo. A seguir descrevemos mais algumas características técnicas que devem ser avaliadas: * custo/benefício da técnica de cabeamento. A técnica de cabeamento e conexão é um dos itens que mais influenciam no custo total de instalação de uma rede; e custo de manutenção e facilidade de diagnosticar problemas; e confiabilidade — as técnicas de detecção e correção de erros são adequadas a sua aplicação? O ambiente onde a rede será instalada possui muito ruído? Confiabilidade pode ser aplicada aos dados, com técnicas como CRC, e no meio de comunicação; e disponibilidade — existem aplicações onde paradas de sistema não são toleráveis. Um exemplo seria uma rede de processadores de um avião, onde a segurança de centenas de pessoas está em jogo. Nesse tipo de aplicação, o protocolo deve conter técnicas de tolerância a falhas visando minimizar a probabilidade de falhas do sistema; e flexibilidade — capacidade de modificação do layout do sistema; e compatibilidade — é importante que vários fabricantes suportem o protocolo escolhido para que você não fique dependendo de um só fabricante, tendo maior liberdade de escolha de equipamentos e de suporte técnico; 28 A especificação completa deste protocolo chama-se EHS specification R1.2 e pode ser encontrada nos links [23] [24] [25]. 4.3.1.1 Arquitetura O modelo de comunicação EHS é semelhante a estrutura do modelo OSI. EHS especifica a camada física, de enlace, de rede e de aplicação, conforme Figura 15. Gerenciamento de Rede TP2 64000 Figura 15 — Arquitetura do protocolo EHS A camada de aplicação traduz a “linguagem” da aplicação em pacotes de dados capazes de circular na rede. A camada de rede está relacionada ao roteamento e endereçamento dos pacotes. A camada de enlace, dividida em MAC e LLC, gerencia a conversão de bits, regras de acesso a rede, recebimento e envio de pacotes e mecanismos de repetição. Várias camadas físicas estão definidas devido ao grande número de aplicações que o protocolo abrange. Rede elétrica, infra-vermelho e rádio podem ser usados como canal de comunicação de baixa velocidade sem a necessidade de cabeamento extra. Um exemplo seria gerenciamento de aquecedores, ar condicionados e acionamentos remotos em geral. Par trançado e cabo coaxial podem ser usados quando se requer alta velocidade, por exemplo, aplicações de vídeo, áudio e segurança. As características de cada meio físico suportado pelo protocolo são mostradas na Tabela 1. 4.3.1.2 Características do Protocolo e Plugand Play; 29 e Interoperabilidade; e Expansionabilidade e configuração automática. 4.3.1.3 Meios Físicos Uma parte importante de um sistema de automação doméstica é o meio de comunicação. A especificação EHS, versão 1.2, cobre seis meios para transportar informações sendo que outros meios ainda poderão vir a ser acrescentados. Meio Par Par Cabo Linha de Rádio Infia- Físico Trançado | Trançado Coaxial Energia RF Vermelho tipol tipol CX PL IR TPI TP2 Aplicação Propósito | telefonia, Audio, controle | telefone controle geral, ISDN, Vídeo, TV, sem fio, remoto controle dados, dados, controle controle controle Taxa de 9.6 Kbps 64 Kbps 9.6 Kbps | 2.4Kbps | 1.2 Kbps | 1.1 Kbps transmissão Acesso CSMAÍCA | CSMA/CD | CSMA/CA | CSMA/ack cT2 - Alimentação 35V 35V 15V 230 Vac - - Codificação - TDM FDM - FDM - Topologia Livre barramento | barramento livre livre livre Unidades 128 40 128 256 256 256 Alcance 500 m 300 m 150/50 m casa 50/200 m sala Tabela 1 — Tipos de meios físicos EHS Os meios mais importantes para o protocolo são o linha de energia e par trançado (TP1). Em um sistema onde o custo é prioridade o uso de linha de energia tem uma grande vantagem em relação a outros meios. Não é necessário cabeamento extra, pois todas as casas possuem um cabeamento da rede elétrica. Vale comentar que o meio por linha de força usa uma técnica de detecção e correção de erros chamada FEC (Forward Error Correction) que adiciona 6 bits de codificação para cada 8 bits de dados. Tal redundância é necessária devido ao elevado nível de ruído que esse meio possui. Os outros meios possuem outro método de detecção de falhas chamado CRC (Cycle Redundancy Check). 4.3.1.4 Estrutura da Rede EHS provê várias implementações de camadas físicas. Com isso a estrutura da rede pode ser formada por várias sub-redes, sendo cada uma baseada em uma camada fisica. Para interligar todas 30 as sub-redes usam-se roteadores, formando um único sistema de controle, como mostra Figura 16. Gateways são usados para interligar a rede EHS em uma rede não EHS. RE-EHS Roteador PL-EHS Roteador TPI-EHS Figura 16 — Estrutura da rede EHS 4.3.1.5 Formato dos Pacotes Não conseguimos um material que detalhasse a função de cada campo, porém podemos destacar o endereço de origem e destino do pacote, FCS como técnica de detecção de falhas e a prioridade da mensagem, como campos auto explicativos. A Figura 17 ilustra o formato do pacote EHS. Figura 17 — Formato dos pacotes EHS 4.3.1.6 Funções do Gerenciamento de Rede EHS provê e integra várias funções de gerenciamento de rede. São explicados abaixo algumas dessas funções. Registro Quando uma nova unidade é instalada no sistema, a sua primeira função é executar o processo de registro. O registro é um processo automático responsável por carregar um novo endereço fisico à unidade. Inscrição 33 a mm & | CABEÇALHO DADOS ce) og TIPO O a m mm q | CABEÇALHO DADOS crc| E (Na [1] a TIPO 1 a m mm & | CABEÇALHO DADOS crc| S Jno ID1 Ibn Eq TIPO 2 a m mm & | CABEÇALHO DADOS cRc| O |nE DADO IFR ecos TPO3 Figura 19 — Tipos de in-frame response 4.3.2.4 Diagrama de Blocos Os próximos itens desta Seção tratam da divisão interna do protocolo: Interface com CPU, Gerenciador de protocolo, Interface MUX. Interface com CPU Esse bloco tem a função básica de fazer a interface do módulo BDLC com a CPU. Ele é composto de cinco registradores que podem ser visualizados na Figura 20. PARA CPU INTERFACE CPU DADO TX CONTROLEISTATUS DADO RX PARA MANIPULADOR DE PROTOCOLO Figura 20 — Interface com CPU e BCRI (Control Register 1) configura e controla o BDLC. Suas funções incluem seleção do clock, habilitação de interrupções e indicação de mensagens que devem ser ignoradas. e BSVR (State Vector Register) indica o estado atual de operação do BDLC. e BCR2 (Control Register 2) controla parâmetros de transmissão. Quando a CPU envia ou recebe um dado, esse dado é passado byte a byte para essa interface sendo armazenado temporariamente no registrador BDR (Data Register). Bytes que serão transmitidos pela CPU devem ser primeiramente escritos no BDR para chegarem ao barramento. Bytes recebidos do barramento serão lidos pela CPU também por esse registrador. e BARD (Analog Roundirip Delay Register) Configura o BDLC para os diferentes tipos de transceivers. Gerenciador de Protocolo A Figura 21 ilustra a estrutura interna do gerenciador de protocolo. PARA INTERFACE CPU CONTROLE [gnapom REGISTER TX] erabcr REGISTER 4] DADO TX 8 DaDo RX [strT-REGisTER TX | [ SHFT-REGISTER Rx | MÁQUINA DE ESTADOS DADO TX | CONTROLE DADO Rx PARA INTERFACE MUX Figura 21 — Gerenciador de protocolo e A máquina de estados tem a função de controlar todas as operações do protocolo. Suas funções são controle de acesso ao barramento, formação do pacote, detecção de colisão, arbitração, geração e verificação de CRC e detecção de erros. e O Shift-Register RX tem a função de receber serialmente os dados do barramento e enviar para o Shadow-Register RX paralelamente. e O Shift-Register TX tem a função de receber paralelamente os dados do Shadow-Register TXe enviá-los serialmente à máquina de estados. e O Shadow-Register RX é um buffer entre o Shift-Register RX e o BDR. Analogamente, o Shadow-Register TX é um buffer entre o BDR e o barramento. Interface MUX A Figura 22 ilustra a estrutura interna do MUX interface. 35 PARA MAMIPULADOR DE PROTOCOLO, CODIDECOD DE siMBOLO | avo rx FILTRO DADO TX DIGITAL RX DADO RX MULTIPLEXADOR] LOGPBACH LG TX . Rx PARA INTERFACE FÍSICA Figura 22 — Interface multiplexador e O codificador e decodificador de simbolo tem a função, em modo de transmissão, de receber dados serialmente do gerenciador de protocolo e codificá-los para o barramento. Analogamente o decodificador recebe os dados do barramento, decodifica-os e envia-os ao gerenciador de protocolo. e O filtro de ruído tem a função de verificar se o sinal de entrada é um ruído. Essa verificação é baseada no tempo de duração do sinal. Sinais curtos serão descartados, pois o circuitos interpreta-os como um ruído. e O Multiplexador Loopback tem a função de isolar o módulo BDLC da interface física se o sinal de transmissão estiver conectado ao bloco de recebimento. 4.3.2.5 Método de Acesso ao Barramento O algoritmo de acesso ao barramento baseia-se en CSMA/CD+AMP que é um método não destrutivo que permite que mensagens com prioridade maior sejam transmitidas. Os nodos que perderam a disputa pelo meio fisico simplesmente ficam em estado de leitura aguardando o meio ficar liberado novamente para começarem a transmitir novamente. O tratamento de colisão ocorre da seguinte forma: o nodo envia um bit para o barramento, lendo o estado do barramento após o envio. Se o valor lido foi diferente do valor enviado, é sinal que esse nodo perdeu o acesso ao barramento para um nodo com mensagem de prioridade maior. O nodo que perdeu o acesso entrará em estado leitura do barramento até que o barramento seja novamente liberado. O nodo que ganhou a disputa pelo barramento continuará a enviar a sua mensagem. 38 IDLE |conTROLE | ENDEREÇO | DADOS | PARIDADE | IDLE ACK ILE ABYTE 4BrTES DABBVTES ABYTE ABYTE 2BVTES 2BVTES Figura 24 — Pacote EIB Os meios físicos de comunicação disponíveis são: e EIB.TP — Par Trançado. A taxa de transferência é de 9600 Bit/s. O comprimento máximo por sub-rede é de 1000m. e EIB.PL — Linha de Energia. Usa modulação SFSK (Spread Frequency Shift Keying). A distância máxima entre dois dispositivos, sem necessidade do uso de repetidores, é de 600m devido ao alto nível de ruído que esse meio possui. e EIB.RF — Rádio Freqgiência. Sem retansmissores tem-se um alcance de 300m. O ponto forte desse protocolo e o método de acesso ao meio, que possibilita uso em aplicações críticas em tempo real. Porém o que nos levou a rejeitar esse protocolo foi a falta de literatura detalhada que especificasse o protocolo, o fato de ser um protocolo mais restrito à Europa e a taxa de transferência de 9600bps. Também descobrimos que equipamentos que utilizam esse protocolo são em torno de 10 a 100 vezes mais caros que equipamentos similares. 4.3.5 X-10 O Sistema X-10º é um protocolo de controle baseado em linha elétrica residencial. O sistema consiste basicamente de um controlador (transmissor) e um interruptor remoto (receptor). Os controladores X-10 enviam sinais digitalmente codificados aos módulos de recepção através da tede elétrica de 120VAC já existente. O interruptor remoto pode ser conectado a qualquer saída de tensão. Um eletrodoméstico é conectado a um receptor, que continuamente monitora a linha elétrica por sinais codificados. Os sinais são recebidos e interpretados por um circuito eletrônico embutido no receptor. Um comando é transmitido em onze ciclos de linha AC. Um comando válido deve começar com o “Start Code” 1110, e demora dois ciclos, meio para cada bit, para ser enviado. Os próximos quatro ciclos são para enviar os quatro bits do campo “House Code” que, por causa do complemento explicado abaixo, deve ser duplicado. Os últimos cinco bits é o “key code”. A Figura 25 mostra o formato do pacote x-10. º X-10 Home Page (http:/Awww.x-10.com/ 39 Cliclos de Linha de Energia a 5 “ 2 pp EE py START | HOUSE | HUMEER| SIMRT | HOUSE |NUMEER code | ocê |Neooe"| ce” | oe |Meode Figura 25 — Pacote do protocolo X-10 O controlador envia um série de sinais para o receptor, de acordo com a Figura 26. HOUSE CODES KEY CODES H1 H2 H4 H8 D1 D2 D4 D8 DI6 ao 1 10 101100 E1 110 z1 1100 coolo 300100 D1 0 10 41 0100 E 0 001 500010 F1 001 e1 0010 so101 20 1010 HI 1 01 21 1010 rIod11al 201110 J17 111 Wi 1110 Ko o1a uooi1iaio LI o11 11 0110 MO 000 30 00 0 0 N1 000 1 0000 oo10oo 5 0 1000 PI 100 16 1 1000 ANUnitsOff 0 O 0 0 1 ANLightsOn O O 0 11 O 0 010 1 ot o o111 Dim 0 1001 Bright 0 1 0 11 All Lights o1101 Extended Code O 1 111 HailRequest 1 O 0 0 1 HailAcknowledee 1 O 0 1 1 Pre-SetDim 1 0 1 X 1 Extended Data (analop) 1 1 0 0 1 Statuson 1 1 0 11 Statusott 1 1 1 01 Status Request 1 1111 Figura 26 — Tabela de comando do protocolo X-10 A vantagem de se usar linha elétrica da casa como meio de transmissão é que não se necessita cabeamento extra para instalação do sistema. Isso reduz o custo de sua implementação. Porém, linha de energia não é um meio de comunicação ideal devido ao ruído, flutuações e interferências que este meio possui. Para conter essas interferências são necessárias técnicas adicionais para verificar erros nos pacotes. X-10 usa o método “1 e complemento” que consiste em enviar, por exemplo, um bit 1 e logo após o seu complemento 0. Isso traz uma duplicação de dados enviados e uma diminuição do desempenho do sistema, porém tem a vantagem de ser de fácil implementação. A Figura 27 ilustra essa técnica. [Start Code] Fipe Fafe mp: RpemapenepeDe 1110011010911018100101 War said 10 | e mo no mos Start Code House Code “4º Key Humber “2 Figura 27 — Método de detecção de erros do protocolo X-10 40 As grandes vantagens do protocolo X-10 são sua simplicidade e o uso linha elétrica como meio físico. Isso leva a uma diminuição de custo de implementação e facilidade de manutenção e instalação, o que muitas vezes pode ser feito pelo próprio consumidor. Essas vantagens foram marcantes para X-10 ser o protocolo específico para automação doméstica mais famoso e usado. Porém, como neste trabalho temos que manter um compromisso com a oportunidade de aprendizado prático, decidimos não optar pelo uso deste protocolo justamente por ser simples ao ponto de dificultar a aplicação deste protocolos para aplicações mais exigentes a nível de protocolo como entretenimento, onde uma alta taxa de transmissão é exigida. 4.3.6 Consumer Electronics Bus - CEBus CEBus!º foi desenvolvido visando o mercado norte-americano. Este protocolo apresenta as seguintes características: e Arquitetura aberta; e Expansível; e Comunicação e Controle Distribuído. Não necessita de um controlador centralizado; e Plug and Play. CEBus possui os seguintes meios de comunicação: e PLBus — Linha elétrica; e TPBus — Par trançado. Normalmente usado para aparelhos de baixa potência; IRBus — Infra-vermelho a 10kbps/s com fregiiência portadora de 70 a 80 KHz; e RFBus — Rádio frequência que opera a 902MHz; e CXBus — Cabo coaxial. Normalmente usado em circuito de TV. CeBus pareceu, segundo as informações que dispúnhamos, ser um protocolo muito bem especificado, visando o crescimento futuro que o ramo de automação doméstica está tendo. Sua flexibilidade e facilidade de instalação são o seu diferencial. Porém a escassez de material técnico gratuito impossibilitou maiores análises do protocolo. A especificação do padrão"! é vendida à U$42,00. !º Consumer Electronics Bus (http:/Awww.cebus.org/ “ CEBus Standard (EIA-600) 43 5 Controller Area Network - CAN Controller Area Network é um protocolo serial que suporta controle em tempo real distribuído, com um grande nível de segurança [10] [13] [12] [14] [15]. Foi originalmente desenvolvido para aplicação automotiva, mas hoje em dia já existem muitas outras aplicações que serão citadas na Seção 5.1. Existe muito material sobre CAN disponível gratuitamente na Internet. Entre os principais citamos os links [10] [11] [12]. Este capítulo não tem a função de ser um manual sobre CAN, e sim de dar ao leitor uma visão das características principais do protocolo que será a base desse trabalho. Na Seção 5.1 citamos algumas aplicações do protocolo CAN. Na Seção 5.2 apresentamos conceitos básicos sobre CAN. A Seção 5.3 apresenta em detalhes a especificação do protocolo CAN, bem com suas características. A Seção 5.4 apresenta algumas variações de implementações existentes. Na Seção 5.5 é feito o estudo a nível de diagrama de blocos da arquitetura que será implementada no Trabalho de Conclusão 2. 5.1 Aplicações de CAN Uma das principais preocupações que tivemos para escolher o protocolo a ser implementado é a flexibilidade a nível de aplicações que ele pode ter. Por esse motivo, escolhemos um protocolo que não restrinja as aplicações somente ao âmbito deste trabalho. Entre as principais aplicações citamos: e veículos (marítimo, aéreo, terrestre) — carros de passeio, off-road, trens, sistema de semáforo (trens e carros), eletrônica marítima, máquinas agricolas, helicópteros, transporte público; e sistema de controle industrial — controle de planta, de maquinário, de robôs, sistema de supervisão; e automação predial — controle de elevadores, de ar condicionado, de iluminação; e aplicações específicas — sistemas médicos, telescópios, simuladores de vôo, satélites artificiais, entre outros; 44 Neste trabalho propomos uma nova aplicação a CAN. Essa aplicação é um sistema de supervisão de domótica via web usando o protocolo CAN como rede de controle da casa. 5.2 Conceitos Básicos Nesta Seção alguns conceitos básicos são explicados para facilitar o entendimento das seções seguintes. CAN possui as seguintes características: * priorização de mensagens; e garantia do tempo de latência (tempo real); e flexibilidade de configuração; * recepção multicast com sincronização; e várias técnicas para manter consistência de dados; e multi-mestre; e técnicas de detecção e sinalização de erros; e desligamento automático de nodos com defeitos; CAN é dividido em diferentes camadas de acordo com o modelo OSI /ISO: e Camada de enlace: e sub-camada LLC (Logical Link Control); e sub-camada MAC (Medium Access Control); e Camada fisica; As funções de cada camada podem ser visualizadas na Figura 28, sendo explicadas na Seção 5.3. 45 Camada de Enlace LLC - Serviços de transferência de dados e requisição remota; - Filtro de aceitação; - Notificação de overload; - Recuperação. MAC - EnDe-Capsulamento de dados; - De-iCodificação de pacotes; - Bit stuffing; - Gerenciamento de acesso ao meio; - Detecção de erros; - Sinalização de erros; - Reconhecimento; - Serialização. Camada Física - En-Codificação de bit; - Temporização de bit; - Sincronismo. Figura 28 — Funções das camadas de CAN O barramento CAN possui dois valores. dominante, equivalente ao nível lógico 0, e o recessivo, equivalente ao nível lógico 1. Na ocorrência de duas escritas simultâneas no barramento, uma escrita dominante (0) e outra recessiva (1), o barramento estará com valor dominante, pois, como o próprio nome diz, esse tem prioridade em relação ao recessivo. Existem duas especificações sobre o protocolo CAN. A primeira é chamada Standard CAN e a segunda Extended CAN. A Tabela 4 faz um comparativo entre as duas especificações [12]. Standard CAN Extended CAN Nome da Especificação CAN20A CAN20B Número de bits do campo de q 29 identificação Tabela 4 — Comparativo entre CAN padrão e estendido 5.3 Especificação CAN As seções subsequentes têm como objetivo detalhar a especificação padrão do protocolo CAN [12] [13]. Na Seção 5.3.1 apresentamos o formato e função dos pacotes CAN. A Seção 5.3.2 descreve as técnicas de detecção de erros existentes no protocolo CAN. A Seção 5.3.3 explica o algoritmo de arbitração usado na disputa pelo barramento. Nas Seções 5.3.4 e 5.3.5 é explicada a técnica de 48 mensagem enviando um bit dominante no ACK Slot. Isso indica ao transmissor que ao menos um nodo recebeu a mensagem corretamente; e EOF-—7 bits — todos recessivos - EOF (End Of Frame) delimita o fim de uma mensagem. Bit stuffing é desativado enquanto EOF está ativo; e IDLE —0 oumais bits — recessivos — Sinaliza que o barramento está livre. Qualquer nodo pode começar uma transferência de mensagem; * Intermission ou IFS (InterFrame Space) — 3 bits — recessivos — IFS é o tempo necessário para que um nodo transfira um pacote corretamente recebido do barramento para área de armazenamento local (mailbox). É o tempo mínimo entre a transmissão de dois pacotes ( tempo interno para nodo processar o pacote ). 5.3.1.2 Pacote de Requisição de Dados É possível que um nodo de destino requisite dados da origem. Para isso o nodo de destino envia uma requisição de dados (RFR") com o identificador que pertence ao dado requerido. O nodo que tem este dado devolverá um pacote de dados, respondendo à requisição. A Figura 31 ilustra o funcionamento de RFR. O nodo 1 envia uma requisição de dados com o identificador do mesmo, indicado pela marca (1) na figura. O nodo que responde por esse dado (identificador) é o nodo 2. O nodo 2, então, envia o dado requisitado (marca (2)) ao barramento e os nodos 1 e 4 lêem este dado (marca (2)). Modo 1 Nodo 2 Nodo 3 Nodo 4 (Consumidor) (Produtor) (Consumidor) (Consumidor, Protocolo Protocolo Protocolo Protocolo Barramento Figura 31 — Requisição remota de dados Existem duas diferenças entre pacotes de dados e pacotes RFR. Primeiramente o bit RTR é transmitido dominante em pacotes de dados e recessivo em RFR. A outra diferença é que não 13 Remote Frame Request 49 existe campo de dados em RFR. Quando um pacote de dados e um RFR com mesmo identificador são transmitidos no mesmo instante, o pacote de dados ganha a disputa devido ao bit RTR dominante. Assim, o nodo que requisitou o dado recebe-o imediatamente. A Figura 32 ilustra o formato deste pacote. ns Arbitração| Controle | CRC | ACK | EOF | 1Bit 120u32Bit Bit 18Bit 2Bit 7Bit 3Bit Figura 32 — Pacote de requisição de dados CAN 5.3.1.3 Pacote de Erro Um pacote de erro é gerado por qualquer nodo que detecte um erro. Sua função, por tanto, é notificar a ocorrência de falhas. O pacote de erro é formado por dois campos: flag de erro e delimitador de erro. A Figura 33 mostra o formato do pacote de erro. Condição de Erro Pacote Incompleto 6 Bit 0...6 Bit 8 Bit 3 Bill tivo —» — Error ante) Flag jm Interirame i Delimitador | Space recessivo) t À de Erro + H—— Pacote de Eno ——— Figura 33 — Pacote de erro CAN e Flag de Emo 6 bits — É o campo que sinaliza a existência de um erro. Existem dois tipos de flag de erros: flag erro ativo e flag erro passivo. Um nodo em estado de erro ativo envia um flag de erro ativo (dominante), enquanto um nodo em estado de erro passivo envia um flag de erro passivo (recessivo). A diferença entre os estados é melhor explicada na Seção 5.3.2.6. O campo de flag de erro é enviado pelo nodo que detectou o erro (receptor 2 na Figura 34) e, se esse nodo estiver em estado ativo (dominante), sobrescreverá o dado corrompido. Quando os outros nodos da rede recebem a sequência de 6 bits dominantes referente ao flag de erro, irá ocorrer uma violação de bit stuffing e todos os nodos (receptor 1) enviarão ao mesmo tempo um outro flag de erro. Os próximos 6 bits são esse segundo flag de erro que é enviado, em dominante, pelos outros nodos da rede. 50 Transmissor dado dado Sbt |3 Receptor 1 5 bit Receptor 2 6 hit Barramento receptor 2 detecta um erro e torna-o público para os outros nodos Figura 34 — Processo de sinalização de erros Se o nodo que identificou o erro está em modo erro passivo, ele enviará um flag de erro recessivo e mais o delimitador, também em recessivo. Portanto erros sinalizados por nodos em estado de erro passivo não afetarão o barramento, isolando assim nodos que tenham uma taxa de erros grandes. e Delimitador de Erro — 8 bits (recessivos) - É transmitido pelo nodo que enviou o dado que continha erro. Sua função é recomeçar comunicações no barramento após uma falha. 5.3.1.4 Pacote de Overload E usado, basicamente, para sinalizar a um transmissor que o receptor não está pronto para receber as próximas mensagens, portanto o transmissor deve esperar para fazer a próxima transmissão. O formato do pacote é idêntico ao pacote de erro com a diferença que Overload Flag é sempre dominante e que o envio de um pacote de overload ocorre sempre após os 3 bits de IFS, ou seja, depois do fim de um mensagem. 5.3.2 Técnicas de Verificação e Sinalização de Falhas Esta Seção apresenta as técnicas de detecção de erros implementadas no protocolo CAN. 5.3.2.1 Bit Stuffing Nos pacotes de dados e de RFR é usada a técnica de bit stuffing para assegurar a não existência de um número maior que 5 bits de mesmo nível lógico consecutivo. Isso é usado para garantir a sincronização de todos os nodos da rede e também aumenta a imunidade a ruído. 53 l Reset REC => 12704 cmo) TEC=> 127 Reset REC < 12704 TEC < 127 —e TEC >255 REC: Recelvo Error Counter TEC: Transmit Error Counter Figura 36 — Estados de erro 5.3.2.7 Análise de Detecção de Erros A probabilidade [13] de não se detectar um falha em um nodo CAN padrão é: p<47x 107! xtaxa de erro Exemplo: Suponha que ocorra um erro a cada 0.75 a uma taxa de transferência de 500Kbits/s, que a rede esta em funcionamento 8 horas por dia, 365 dias por ano. Com isso conseguimos um valor médio aproximado de uma falha não detectada a cada 1000 anos. Em pacotes estendidos a probabilidade de não detectar uma falha geralmente é maior do que em pacotes padrões. 5.3.3 Arbitração Se dois ou mais nodos começam a transmissão no mesmo instante, a colisão das mensagens é evitada pela implementação do protocolo CSMA/CD+AMP para decidir disputas de acesso ao barramento. O campo de identificação dos pacotes conterá não somente a identificação do dado, mas também a prioridade que essa mensagem terá. Identificadores de menor valor terão maior prioridade. Enquanto os nodos estiverem enviando os mesmos bits de identificação, nada acontece. No entanto, quando um nodo enviar um bit de identificação de prioridade menor, esse perderá a disputa pelo barramento. A Figura 37 mostra como ocorre a arbitração. Até o bit 6 todos os nodos enviaram o mesmo valor. Porém, no bit 5 o nodo 2 transmitiu um bit recessivo, perdendo assim a disputa para o nodo 3 e 1. No bit 2 o nodo 1 enviou um bit recessivo e entrou em modo de escuta. Desta forma, o nodo 3 ganhou a disputa pelo barramento e seguiu transmitindo o pacote. 54 identificador Fjoss 76543240 controle) dado Nodo 1 Leitura Nodo 2 Leitura Nodo 3 tecessivo Barramento dominante Figura 37 — Arbitração CAN 5.34 Bit-Timing Uma rede CAN consiste de vários nodos, cada um com o seu clock individual. Por esse motivo podem ocorrer perdas de fase nos diferentes nodos. Os nodos CAN possuem um algoritmo de sincronização que compensa perdas de fase enquanto estão recebendo um pacote. Um Bit Time é o período de transmissão e recepção de um bit. Todos os nodos da rede devem ter o mesmo bit time. Bit time é formado por quatro segmentos: sync seg, prop seg, phase segl e phase seg?. Cada segmento é formado por múltiplos Time Quanta (tg). O Time Quantum é uma unidade de tempo fixa (menor porção de tempo usada no nodo CAN) derivada do clock do sistema. e SYNC SEG- 1 tq- É usado para sincronizar os vários nodos. Espera-se que a borda de descida em uma recepção ocorra neste segmento (caso ideal); e PROG SEG-1..8 tq — É um campo de largura variável usado para compensar o atraso de sinais através da rede; e PHASE SEGI - 1.8 tg — É usado para compensar o erro de fase e pode ter seu comprimento aumentado durante a resincronização; e PHASE SEG? - 1.8 tg — É usado para compensar o erro de fase e pode ter seu comprimento diminuído durante a resincronização; e SAMPLE POINT !º — É o instante onde o nível do barramento deve ser lido para ser interpretado como valor do respectivo bit. 16 Ponto de Amostragem 55 A Figura 38 mostra o formato de um Bit Time. | Sinal de Entrada ] Bit-Time , SYNC SEG | PROP SE! HASE SEG1|PHASE SEG2 Ponto de Amostragem Figura 38 — Bit Time CAN Também podemos observar na Figura 38 que a borda de descida do sinal de entrada ocorre no segmento sync seg do bit time. Está a situação ideal de comunicação, pois não existe diferença de fase entre o transmissor e o receptor. 5.3.5 Sincronismo Duas técnicas de sincronização são suportadas: Hard Synchronisation e Soft Synchronisation. e Hard Synchronisation — É acionado na borda de descida quando o barramento está livre, que é interpretado como SOF. Essa sincronização inicia a lógica interna de bit time. e Soft Synchronisation — É usado para ajustar o bit time enquanto o nodo CAN está recebendo um pacote. Quando o transmissor é lento em relação ao receptor o bit time é aumentado. Quando o transmissor é mais rápido o bit time é diminuído. A cada borda de descida inicia-se a lógica de bit time. Idealmente essa borda é esperada no segmento sync Seg, conforme Figura 38. Porém pode acontecer, devido a alteração de fase, que a borda de descida venha a acontecer durante o segmento phase Segl ouphase Seg?. Se a borda de descida do sinal de entrada for detectada quando o bit time estiver no segmento phase Segl (Figura 39) interpreta-se que o transmissor é lento em relação ao receptor. Neste caso o segmento phase Segl é adicionado de RJW pulsos para que o sinal de amostra esteja no ponto adequado (ponto 2). Se não houvesse um sistema de sincronização, o sinal seria amostrado no ponto 1 da figura. 58 Para se fazer a interface do controlado CAN com o barramento é necessário que exista um transceiver para fazer a codificação do sinal do controlador para sinal de tensão diferencial, do barramento ( Figura 44). Te CAN H k ou a lara sv T n 2 d ra É ç Nov 2” ov H d r d sv ; Rx | CAN L Figura 44 — Transceiver A taxa de transferência máxima de uma rede CAN é de 1Mbit/s. Porém essa taxa varia de acordo com o comprimento da rede devido à resistência dos fios do barramento. A Tabela 6 mostra essa relação. Pode-se conseguir maiores comprimentos para uma mesma taxa caso exista na rede elementos chamados de repetidores, que têm a função de reforçar o sinal elétrico para que esse possa percorrer maiores distâncias. Taxa (Kbit/s) Comprimento(m) 1000 30 500 100 250 250 125 500 62.5 1000 Tabela 6 — Taxa de transferência x comprimento do barramento 5.4 Implementação Apesar da especificação CAN ser bem direcionada, o desenvolvedor tem liberdade de escolha na implementação de certos itens de um controlador CAN. 5.4.1 Variação Quanto à Integração Quanto a integração de componentes podemos citar três variações: 59 e Stand-alone — Controlador CAN é separado do microcontrolador e do transceiver. É desenvolvido para fazer interface com diversos processadores diferentes permitindo reutilização de código. Um código desenvolvido para um periférico CAN integrado pode não funcionar em outra CPU. A Figura 45 ilustra essa idéia. Micro - controlador Controlador CAN Sinais de controle Figura 45 — Módulo CAN Stand-alone e Integrado — O Controlador CAN é integrado com o microcontrolador. Módulos CAN integrados são mais baratos que Stand-alone não só pelo preço do módulo, mas também pela maior facilidade de desenvolver a placa de circuito impresso, uma vez que terá componentes a menos na placa. Também existe a vantagem da diminuição, em geral pela metade, da carga da CPU uma vez que o endereçamento ao controlador CAN vai ser feito por endereçamento interno que é mais rápido que endereçamento externo. A Figura 46 ilustra esse conceito. Transceiver CAN Microcontrolador CAN H Re | + Módulo CAN Módulo CPU CAN L Tx “—H Figura 46 —- Módulo CAN Integrado e Single Chip — Integra um único chip o transceiver, o controlador CAN e o microcontrolador. Esse nível de integração é relativamente novo, pois possui um problema de implementação que é a integração de diferentes tecnologias em um mesmo chip. A Figura 47 ilustra esse conceito. 60 Microcontrolador Transceivor Móclulo CAN Módulo CPU Figura 47 - Módulo CAN Single-Chip 54.22 Variação Quanto à Armazenamento de Mensagens Quanto ao armazenamento das mensagens, existem duas diferentes implementações: BasicCAN e FullCAN. e BasicCAN — É uma implementação de CAN com buffers intermediários para fazer a interface entre o controlador CAN e o microcontrolador. O tipo mais simples é o com dois buffers para recepção e um para envio de mensagens. Podem existir variações de número de buffers. A Figura 48 ilustra essa arquitetura. sinais de controle Buffer TX x Interface CPU Controlador de Protocolo 4 filtro de " Buffer RX aceitação º Buffer RX Figura 48 — BasicCAN e FullCAN — A interface entre o microcontrolador e o controlador CAN é dada por uma memória RAM dual-port . 63 Nesta figura podemos verificar que a troca de mensagem entre a aplicação do usuário e o módulo CAN ocorre através da memória. Apenas alguns sinais de controle os interligam diretamente. É importante salientar que a aplicação do usuário é o mestre da memória, por isso ela tem a necessidade de informar ao módulo CAN quando essa vai ter acesso a memória. Para essa implementação é desejável o uso de memória dual-port. No caso de envio de uma mensagem a aplicação do usuário escreve na posição relativa a mailbox de transmissão o dado a ser transmitido. Então sinaliza, através dos sinais de controle, para iniciar o envio. Desta forma, o módulo CAN lê o dado da memória e envia-o pela rede CAN. Durante a recepção de dados, o dado recebido será armazenado temporariamente no módulo CAN. Quando todos os bits do identificador do pacote for recebido, é verificado se esse pacote é aceito. Se não for aceito, o pacote será rejeitado. Caso seja aceito, o pacote continuará a ser 1ecebido até o final, e então será gravado na mailbox de recebimento localizada na memória RAM e sinalizado à aplicação do usuário o recebimento de uma mensagem. A Figura 53 mostra a estrutura detalhada do módulo CAN. A função de cada bloco é citada a seguir : e Tx — bloco que executa o envio de dados. Também é responsável por fazer bit-stuffing e arbitração; e Rx — bloco que executa o recebimento de dados. Também é responsável por remover siuffing, fazer sincronização e timing do nodo; e Tx/Rx Shift Register — faz a conversão de paralelo para serial (transmissão) e serial para paralelo (recebimento); e CAN FSM é a parte de controle do módulo CAN. É responsável pelo gerenciamento de ações e tomadas de decisão. Entre suas principais ações citamos : e identificação e classificação de erros; e controle do Tx/Rx Shift Register; e controle da interface de aplicação do usuário e memória; e geração de endereços para memória; 64 RG fe Y A v TadlRx Shit Register Interface e aplicação Nemória aplicação Figura 53 — Estrutura detalhada do módulo CAN A Figura 54 expande as funcionalidade do bloco de interface com memória e aplicação do usuário. O bloco mailbox é uma área de armazenamento temporário de envio e transmissão de dados interna ao módulo CAN. O bloco aceitação verifica se, em caso de recebimento, o pacote interessa a esse módulo. o bloco erro é responsável pela alteração dos registradores de contagem de erros. Controle é responsável pela sinalização de dados entre CAN e aplicação do usuário. —S iiallhox end À controla Nei e Aplicação Figura 54 — Detalhe do bloco de interface com memória e aplicação do usuário 65 68 principalmente devido à facilidade de instalação do ambiente (sistema operacional, linguagens de programação, etc), predominância no mercado e utilização do Windows NT nos laboratórios que foram desenvolvidos o trabalho. 6.2 Escolha da Linguagem De Programação Atualmente existem inúmeras linguagens de programação que são utilizadas para o desenvolvimento de soluções informatizadas das demandas de mercado. No entanto, as linguagens de programação normalmente especializam-se no desenvolvimento de determinados “perfis” de sofiware. O levantamento das prováveis linguagens de programação é um fator importantíssimo que deve ser levado em consideração no desenvolvimento de nosso trabalho, sendo assim, seremos capazes de escolher, de maneira segura, a melhor linguagem para o desenvolvimento do trabalho. Devido à natureza de nosso trabalho, a linguagem de programação a ser escolhida deverá obrigatoriamente dar suporte a utilização da porta de comunicação serial RS-232C, e juntamente possibilitar a comunicação cliente/servidor. Mecanismos de segurança como criptografia e autenticação de usuários também devem ser suportados pela linguagem. Dentre as inúmeras linguagens de programação existentes no mercado, selecionamos aquelas linguagens que de antemão sabemos que possivelmente podem atender nossas necessidades, principalmente porque as mesmas são amplamente utilizadas no desenvolvimento de aplicações Internet. Linguagens como estas possuem fortes princípios de conexões do tipo cliente/servidor (cliente é normalmente o navegador Web utilizado pelo usuário e o servidor irá rodar o programa que irá tratar os comandos vindos do navegador), inclusive também em muitos casos dão suporte à utilização da porta de comunicação serial RS-232C e controle de segurança e acesso. Abaixo segue um levantamento das potenciais linguagens de programação a serem utilizadas no desenvolvimento de nosso trabalho, para cada linguagem foram levantadas as principais características, auxiliando neste caso para termos uma visão ampla das vantagens e desvantagens de cada linguagem, permitindo a escolha segura pela linguagem de programação que mais se adapte ao contexto do trabalho. 69 6.2.1 Java Java [17][25] link é uma linguagem de programação totalmente orientada a objetos, projetada para o desenvolvimento de aplicações em ambientes distribuídos, como a Internet. A aparência de Java é semelhante a linguagem C++, no entanto é muito mais simples do que C++. Java pode ser utilizado para criar aplicações completas que podem rodar em um único computador ou ser distribuídas entre servidores e clientes na rede. Java possui a sintaxe semelhante a linguagem C, possibilitando a facilidade de adaptação para novos programadores que por ventura conhecem a linguagem C. Java não carrega consigo algumas caracteristicas da linguagem de programação C++, aumentando assim a simplicidade de codificação. Podemos citar como exemplo, herança múltipla em C++, Java não traz isso consigo devido a falta de uso prático deste recurso e principalmente devido a dificuldade de utilização. O tamanho das aplicações desenvolvidas em Java são realmente muito pequenas, proporcionando sua maior utilização no desenvolvimento de aplicações de redes. Java é uma linguagem orientada a objetos, facilitando assim a definição de interfaces de comunicação e aumenta a reusabilidade de código. Os programas desenvolvidos em Java são portáveis, uma vez desenvolvido o código fonte, o mesmo é compilado gerando um código intermediário, denominado de bytecode. Este bytecode é interpretado pela Máquina Virtual Java que neste caso responsabiliza-se em gerar as instruções ao hardware especifico. Java possui uma extensa biblioteca de rotinas para o desenvolvimento de aplicações de rede, sendo de muito fácil utilização. Suporta o desenvolvimento de aplicações que utilizam o protocolo TCPAP, HTTP, FTP, etc. A linguagem impossibilita que determinadas operações realizadas pelo programador possam causar a parada de funcionamento do sistema, tornando a linguagem robusta. Por exemplo, a referência a objetos nulos. A máquina virtual se encarrega de verificar a integridade das operações para evitar estes tipos de acontecimentos comuns em outras linguagens de programação. Devido à utilização de Java para o desenvolvimento de aplicações em ambientes de rede e ambientes distribuídos, muitos mecanismos de segurança foram agregados visando o desenvolvimento de aplicações seguras. Java é uma linguagem de programação interpretada. Devido a isso, o just-in-time compiler foi introduzido para o aumento de performance das aplicações Java. 70 O desenvolvimento de aplicações multitarefa é simplificado devido à facilidade de manipulação de threads em Java. Java possui ferramentas que auxiliam na documentação, aumentando a legibilidade e reutilização de classes e métodos. Recentemente, a Sun Microsystems desenvolveu o pacote javax.comm!?, responsável em permitir que aplicações escritas em Java possam enviar e receber dados através das portas de comunicação serial e paralela. 6.2.2 Perl Peil [22] é uma linguagem de programação utilizada principalmente para a manipulação de textos e arquivos. O objetivo principal da criação da linguagem Perl foi devido a necessidade de seu inventor, Larry Wall, de criar relatórios a partir de arquivos texto com facilidade e em um pequeno espaço de tempo, pois o mesmo levava muito tempo desenvolvendo um programa em C ou em outras linguagens para solucionar um problema simples de ser resolvido se a linguagem de programação utilizada fosse mais prática e direta. Além da facilidade de utilização, Perl possui como característica importante a sua portabilidade. Perl surgiu primeiramente para sistemas operacionais Unix. Devido ao seu sucesso entre programadores, foram criadas versões de Perl para o Amiga, Atari ST, Macintosh, VMS, OS/2 e inclusive MS-DOS, Windows NT e Windows 95/98. Perl é uma linguagem interpretada, no entanto, devido a otimizações internas ao interpretador, Perl possui um boa performance durante sua execução. Qualquer requisição de execução de um script Perl verifica a sintaxe do script antes de sua execução. Perl possui a sintaxe semelhante a sintaxe utilizada na linguagem C, possibilitando a facilidade de adaptação de programadores C à linguagem Perl. Perl é uma linguagem fracamente tipada, não necessita da declaração prévia de variáveis antes de suas utilização e muito menos a necessidade de utilização de casting explícitos. Ainda relacionada a facilidade de utilização, Perl utiliza expressões regulares para a manipulação de informações, facilidade na utilização de operações de entrada e saída, 18 java”M CommunicationsAPI - http:/java.sun.com/products/javacommindex.html 73 6.2.5 PHP: Hypertext Prepocessor PHP Jink [28] segue o mesmo contexto de JSP's e ASPºs, no entanto, sua sintaxe é semelhante a linguagem C. PHP é utilizada principalmente devido a rapidez e facilidade no desenvolvimento de aplicações, agregando características da linguagem Perl. PHP não é uma linguagem fortemente tipada, no entanto, permite ao programador a declaração de tipos caso haja necessidade, tornando a linguagem fortemente tipada somente no caso da necessidade desta característica e como em C e Java, permite a utilização de casting explícitos. Utilização de expressões regulares para a manipulação de textos, assemelhando-se mais uma vez com a linguagem Perl. Permite a utilização de estruturas de dados como arrays, struciures, entre outras, no entanto, não é capaz de realizar manipulação de memória através de ponteiros. PHP possibilita ao programador o desenvolvimento de programas orientados a objeto, permitindo a definição de classes, métodos, construtores, herança simples, etc. PHP possui uma biblioteca com aproximadamente 1000 funções, proporcionando a versatilidade no desenvolvimento de aplicações Web. PHP possui suporte de conexão a diferentes tipos de banco de dados de maneira simplificada. Como característica de linguagens de programação utilizadas na Intemet, suporta comunicações entre aplicações através de sockets de maneira simplificada e de fácil utilização. 6.2.6 Comparação entre Linguagens de Programação Visando auxiliar na escolha da linguagem de programação mais apropriada ao desenvolvimento do trabalho, fizemos um quadro comparativo (Tabela 7) com as principais caracteristicas das diversas linguagens de programação estudadas. 74 Java Perl c ASP PHP Sintaxe Semelhante a | Semelhante a C | C VB Script Semelhante a c c Simplicidade Intermediário | Fácil Difícil Fácil Fácil Tamanho Muito pequeno | Pequeno Pequeno Pequeno Pequeno Suporte a orientação a | Sim Não Não Não Sim objetos Portabilidade Sim Sim* Sim* Sim* Sim Suporte a redes Sim Não Sim Não Sim (TCPAP, Sockets, etc) Robusto Sim Sim Não Sim Sim Segurança Sim Sim Sim Sim Sim Interpretado Interpretado/ | Interpretado Compilado Interpretado Interpretado Compilado Performance Muito Boa Mediana Ótima Mediana Mediana Multithreads Sim Não Sim Não Sim Suporte a Sim Não Sim Não Não comunicação Serial Tabela 7 — Comparação entre diversas linguagens de programação *Dependendo da plataforma pode requerer pequenas mudanças no código. 6.2.7 Conclusão A escolha da linguagem de programação apropriada é um passo fundamental para o sucesso do desenvolvimento de nosso trabalho. Conforme descrito na Seção 2, referente a arquitetura do sistema, necessitamos de uma linguagem de programação que permita o desenvolvimento de aplicações Internet. Além disso, necessitamos obrigatoriamente de uma linguagem que possibilite ao computador Servidor enviar e 1eceber dados através da interface serial RS-232C, pois este é o único método de comunicação com os periféricos da casa. No entanto é importante salientar que a linguagem de programação para o desenvolvimento da homepage não necessita obrigatoriamente ser a mesma linguagem utilizada para o desenvolvimento da interface de comunicação através da porta RS-232C. Devido ao pré-requisito de comunicação utilizando a interface RS-232C, podemos descartar primeiramente todas as linguagens que não permitem gerenciar e controlar a interface de comunicação serial RS-232C. Sendo assim, linguagens como Perl, ASP, PHP são descartadas de nossas opções, no entanto, estas linguagens são utilizadas frequentemente no desenvolvimento de aplicações Internet, sendo assim, uma delas será escolhidas para o desenvolvimento da homepage. Dentre as linguagens de programação estudadas, as linguagens que suportam comunicação serial resumem-se à apenas duas: Java e C. 75 Ambas as linguagens são capazes de proporcionar o desenvolvimento de nosso trabalho, no entanto, visando tornar o trabalho portável, flexivel, legível e robusto, será utilizada para o desenvolvimento a linguagem Java, pois além de cumprir com todos os requisitos exigidos, Java é totalmente portável entre plataformas devido a presença da Máquina Virtual Java. Java possui ferramentas de documentação importantes para melhorar a documentação do sistema, facilitando a legibilidade do código através de API's geradas por uma ferramenta de documentação. A Máquina Virtual Java permite um controle sobre as operações executadas pelo sistema, garantindo a integridade do sistema, tornando-o robusto e consequentemente impedindo que falhas no sistema operacional possam acontecer por sua causa. Java possui uma vasta API com a definição de classes e métodos capazes de propiciar o desenvolvimento do sistema de maneira simplificada, aumentando a legibilidade do código e evitando a necessidade de desenvolvimento de rotinas que não estão implementadas na linguagem Cc. Enfim, a utilização de Java como linguagem de programação aumenta a flexibilidade de desenvolvimento do sistema alem de possuir maiores vantagens sobre a linguagem C. A linguagem Java foi escolhida para o desenvolvimento da aplicação que tem o controle sobre a interface de comunicação serial RS-232C, no entanto, a escolha da linguagem de programação para o desenvolvimento da homepage deve ser feita, onde classificamos como linguagens candidatas : Java, Perl, ASP e PHP. Para o desenvolvimento da homepage, foi escolhida a linguagem PHP devido as suas vantagens que serão vistas na Seção 7.1.2. Outras linguagens se fazem necessárias (HTML e Javascript) independentemente se a linguagem de programação principal for PHP, Perl, Java ou ASP. Nas Seção 7.1.1 e 7.3.2 são explicados com maiores detalhes a coexistência entre todas estas linguagens para o desenvolvimento da homepage. 6.3 Arquitetura Servidor/CAN Visando permitir a comunicação entre o servidor e o controlador mestre, devemos determinar um protocolo de comunicação entre ambos, permitindo que o controlador mestre no momento que receber uma sequência de bits consiga interpretá-la de maneira correta, e os envie aos diversos periféricos da residência. Este tópico será descrito na Seção 8.5. 78 79 7 Implementação do Software Durante o decorrer deste capítulo, explicaremos a implementação de software deste projeto. A parte de sofiware é dividida em quatro Seções: arquitetura geral do software (Seção 7.1), arquitetura do servidor (Seção 7.2), arquitetura do cliente (Seção 7.3) e arquitetura do debugger (Seção 7.4). 7.1 Arquitetura Geral do Software Como pode ser visto na Figura 55, a arquitetura do sistema é composta de três grandes blocos que interagem entre si. Estes blocos são o cliente, o servidor e o hardware. Cada bloco possui uma ou mais funcionalidades, sendo que a troca de informações entre blocos garante o perfeito funcionamento do sistema. CLIENTE SERVIDOR HARDWARE Navegador Web HTTP Apache R$-232 Controlador Aplicação Mestre PHP3 Banco de dados Figura 55 - Arquitetura do Sistema 744 Cliente A figura do cliente é representada por um navegador Web. Sua principal função é exibir ao usuário o status de sua residência, além de possibilitar a interação por parte do usuário, permitindo que o mesmo possa realizar comandos remotos na sua residência, como por exemplo desligar a lâmpada da sala, ou capturar a imagem de vídeo de uma câmera na entrada da casa. Devido a aplicação cliente se tratar de um navegador Web, conforme visto na Seção 2, o protocolo de comunicação utilizado para comunicação entre o computador cliente e computador servidor é o protocolo HTTP. Para o desenvolvimento da interface, utilizou-se três linguagens de programação: e HTML -tesponsável por montar estaticamente a interface da aplicação no cliente; 80 e Javascript link[37] — responsável por tornar a interface dinâmica a medida que o usuário interage com a mesma. Também utilizada para gerar atualizações na interface quando ocorreram mudanças na aplicação final (residência); e PHP /ink[28] - Devido a grande interação entre cliente-servidor, linguagens de geração de páginas dinâmicas tiveram que ser utilizadas. Apesar da linguagem PHP ser responsável pela geração de páginas dinâmicas, o funcionamento da linguagem ocorre na máquina servidor, acoplado juntamente com o servidor Web. Maiores detalhes sobre a utilização de PHP serão discutidos no Seção 7.3. Como caracteristica importante, citamos a utilização de controle de sessão no cliente, o que garante a segurança da residência, pois somente através de autenticação eletrônica o usuário possui controle da residência. Para auxiliar o desenvolvimento da interface no cliente, pode-se utilizar um editor de texto qualquer, no entanto, utilizou-se como ferramenta de desenvolvimento o sofiware HomesSite link[34]. Este sofiware foi escolhido devido às facilidades que o mesmo proporciona no desenvolvimento de aplicações utilizando as linguagens de programação empregadas no cliente. 714.2 Servidor O servidor é o computador que está localizado junto à residência do usuário. Dentre as funcionalidades realizadas pelo servidor, citamos : * envio e recepção de pacotes de controle através da porta RS-232; * interpretação dos pacotes de controle enviados pelo controlador mestre; e monitorar a base de dados em busca de alterações no status da aplicação; e atualização da base de dados; e atualização da interface no cliente. A base de dados, no contexto do sistema, serve como gateway entre o computador cliente e o controlador mestre. Ela também é responsável em manter o status da residência, sendo que qualquer alteração no status da residência deve ser gravada na base de dados. A partir do momento que ocorre uma alteração na base de dados, o sofiware que está rodando no computador servidor é 83 de dados em Access não compromete a portabilidade do sistema, pois todos os tipos de dados utilizados no banco de dados são comuns entre fabricantes de banco de dados, o que garante que através de comandos SQL possamos migrar o banco de dados atualmente feito em Access para outros sistemas de banco de dados. Na Figura 56 apresentamos as tabelas utilizadas no sistema, assim como seus respectivos relacionamentos. A seguir, descreveremos detalhadamente todas as tabelas e relacionamentos existentes no banco de dados criado para suportar o sistema proposto no trabalho. A Figura 56 ilustra no canto superior esquerdo a tabela Usuarios. Sua principal função é armazenar os usuários que possuem permissão de acesso à homepage da residência e consequentemente o acesso às aplicações desta. Também indica quais usuários possuem acesso a interface de manutenção de usuários. Na Tabela 8 informações mais detalhadas são fornecidas. à, Microsoft Access - [Relacionamentos] Jzs Arquivo Editar Exibir Relacionamentos Ferramentas Janela Ajuda pPenBayEresjaFeEs|EGD| usuario senha acesso, permitido acesso manutencao dirty mestre dirty servidor nro. perifericos atualizando extensao descricao Figura 56 — Tabelas do Sistema Coluna Tipo Tamanho Descrição Usuario char 10 Nome do usuário 84 Senha char 32 Senha do usuário criptografada pelo algoritmo md5 acesso permitido byte - Indica se o usuário tem acesso a homepage acesso manutencao | byte - Indica se o usuário tem acesso a interface de manutenção de usuários Tabela 8 — Tabela Usuarios As colunas acesso permitido, acesso manutencao são definidas como do tipo byte, no entanto, para o sistema essas colunas tem significado boleano, ou seja, verdadeiro ou falso. Neste caso representamos verdadeiro pelo número 1 e falso pelo número 0. Visando aumentar a segurança e a confiabilidade do sistema, a senha do usuário é criptografada e armazenada no banco de dados. O algoritmo de criptografia utilizado pelo sistema é o md5, com fingerprint de 128 bits (link [30]). O algoritmo md5 é um algoritmo do tipo irreversível e sua principal utilização é comparação de sírings criptografadas. Seu funcionamento é simples, basta uma síring qualquer ser informada e o algoritmo automaticamente retorna outra síring de exatamente 32 bytes. A senha do usuário é armazenada criptografada. A todo momento que o usuário realizar uma tentativa de login no sistema, a senha digitada é criptografada e comparada com a senha existente no banco de dados, se as strings forem iguais e o usuário possuir no banco de dados permissão de acesso ao sistema (coluna acesso permitido), o usuário é aceito pelo sistema. No trecho de código abaixo mostramos como ocorre a criptografia de uma síring através do algoritmo mdS5 utilizando a linguagem PHP. $senha = “futebol”; // a variavel senha recebe a string “futebol” $senha cripto = md5 ($senha); // a variavel senha cripto recebe o resultado da criptografia da string contida na variavel senha (“futebol”) Outra tabela existente no banco de dados é a tabela denominada TabelaNodos. Esta tabela é responsável em armazenar as informações referentes ao periféricos existentes na residência. A Tabela 9 representa a estrutura de dados utilizada na TabelaNodos. Coluna Tipo Tamanho Descrição ID NODO long int - Identificador do NODO (chave primária) classe long int - Classe 85 aplic long int - Aplicação nodo id long int - Nodo id tamanho long int - Tamanho dos dados dirty mestre byte - Dirty em relação ao mestre dirty servidor | byte - Dirty em relação ao servidor nro perifericos |long int - Número de periféricos atualizando byte - Indica se o registro está sendo atualizado extensao char 5 Em caso de pacotes maiores que 8 bytes indica com qual extensão o arquivo deve ser salvo descricao char 50 Descrição do tipo de aplicação Tabela 9 — Tabela TabelaNodos Os campos desta tabela de nodos são descritos abaixo. ID NODO — é a chave primária da tabela e sua principal função é permitir o relacionamento entre a TabelaNodos com a TabelaDados. Informações mais detalhadas sobre este 1elacionamento serão apresentadas nas próximas páginas; classe — representa a classe da aplicação dentro da residência. Exemplo: iluminação, refrigeração; aplic — representa a aplicação propriamente dita. Exemplo: dentro da classe iluminação existe a aplicação lâmpadas, dimmers, etc; nodo id — representa um conjunto finito de aplicativos de uma mesma aplicação; tamanho — indica o número bytes utilizado para que a aplicação seja controlada; dirty mestre — indica que o controlador mestre está desatualizado em relação a base de dados; dirty servidor — indica que o estado da base de dados foi alterado e o servidor deve enviar comandos para a atualização da interface cliente; nro perifericos — indica o número de periféricos existentes para uma aplicação; atualizando — indica que o registro está sendo atualizado e garante que aquele registro não seja lido antes de sua atualização ser considerada concluida; extensao — o envio/recepção de pacotes maiores que 8 bytes ocorrem normalmente para arquivos transportando imagens, vídeos, etc. Neste caso existe a necessidade de sabermos qual é o tipo de arquivo que trafega para uma determinada aplicação, pois no término do processo de envio, o