UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO – BACHARELADO
CONTROLE DE TRÁFEGO FERROVIÁRIO UTILIZANDO
MICROCONTROLADOR PIC16F628A
ANDREY STARKE SARDO
BLUMENAU
2007
2007/1-06
ANDREY STARKE SARDO
CONTROLE DE TRÁFEGO FERROVIÁRIO UTILIZANDO
MICROCONTROLADOR PIC16F628A
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso II do curso de Ciências
da Computação — Bacharelado.
Prof. José Roque Voltolini da Silva - Orientador
BLUMENAU
2007
2007/1-06
CONTROLE DE TRÁFEGO FERROVIÁRIO UTILIZANDO
MICROCONTROLADOR PIC16F628A
Por
ANDREY STARKE SARDO
Trabalho aprovado para obtenção dos créditos
na disciplina de Trabalho de Conclusão de
Curso II, pela banca examinadora formada
por:
Presidente:
______________________________________________________
Prof. José Roque Voltolini da Silva – Orientador, FURB
Membro:
______________________________________________________
Prof. Miguel Alexandre Wisintainer, Mestre – FURB
Membro:
______________________________________________________
Prof. Antônio Carlos Tavares – FURB
Blumenau, 10 de julho de 2007
Dedico este trabalho a meus pais José Sardo
Filho e Eliane Starke Sardo, que me ajudaram
direta e indiretamente na realização deste.
AGRADECIMENTOS
Aos meus avôs Harold e Lucia, mesmo que indiretamente, me ajudaram com
pensamento positivo e acreditando em mim.
Aos meus amigos, que mesmo em situações difíceis sempre estiveram ao meu lado,
não só no curso, mas durante toda a minha vida.
À Gislene, pelo seu carinho e paciência.
Ao professor Miguel, pelas dicas que foram fundamentais para o trabalho.
Em especial ao meu orientador, José Roque Voltolini da Silva, pelo incentivo e ajuda
que me deu na confecção do trabalho, e por ter acreditado na conclusão deste trabalho.
Procure ser uma pessoa de valor, em vez de
procurar ser uma pessoa de sucesso. O sucesso
é conseqüência.
Albert Einstein
RESUMO
Este trabalho apresenta o desenvolvimento de um sistema de controle de malha ferroviária
bem como a montagem de um protótipo. Para a construção do hardware e o controle de trens
e cruzamentos foi utilizado o PIC16F628A e o componente TRF-2.4G para transmissão de
dados. É desenvolvido também o software embarcado dos microcontroladores e o software
que gerencia todos os dispositivos envolvidos na malha.
Palavras-chave: Sistemas embarcados. Sistemas de controle. Controle de malha ferroviária.
ABSTRACT
This work presents the control’s development’s system of railroad as well as the assembly of
a prototype. For the construction of the hardware and the control’s of trains and crossings it
was used the PIC16F628A and the component TRF-2.4G for transmission of data. It is also
developed the embedded software of the microcontrollers and the software that manages all
the involved devices in the railroad.
Key-words: Embedded systems. Systems of control. Control of railroad.
LISTA DE ILUSTRAÇÕES
Figura 1 – Pinagem do PIC16F628A ....................................................................................... 19
Figura 2 – Exemplo de saídas do PWM ................................................................................... 21
Figura 3 – Componente TRF-2.4G........................................................................................... 23
Quadro 1 – Funcionalidade dos pinos do TRF-2.4G................................................................ 23
Figura 4 – Funcionamento do modo ShockBurst...................................................................... 24
Quadro 2 – Exemplo de código utilizando classe da API RX/TX ........................................... 25
Quadro 3 – Exemplo de código utilizado para enviar bytes..................................................... 25
Figura 5 – Visão geral da maquete ........................................................................................... 26
Figura 6 – Visão do trem desenvolvido por Schubert (2003) .................................................. 27
Figura 7 – Visão do cruzamento desenvolvido por Schubert (2003) ....................................... 27
Figura 8 – Interface de execução da aplicação desenvolvida por Raulino............................... 28
Figura 9 – Utilização de reed-switch como sensores ............................................................... 29
Quadro 4 – Características dos trabalhos correlatos................................................................. 29
Figura 10 – Ligação entre componentes do sistema................................................................. 32
Figura 11 – Diagrama esquemático do controlador.................................................................. 33
Figura 12 – Diagrama esquemático do trem............................................................................. 34
Figura 13 – Diagrama esquemático do cruzamento ................................................................. 35
Figura 14 – Diagrama de casos de uso ..................................................................................... 36
Figura 15 – Diagrama de classes .............................................................................................. 36
Figura 16 – Modelagem da malha do protótipo ....................................................................... 37
Quadro 5 – Representação da modelagem da malha representada na fig. 16 .......................... 38
Figura 17 – Diagrama de Nassi-Schneiderman do controlador................................................ 39
Figura 18 – Diagrama da rotina para enviar dados para o TRF-2.4G ...................................... 39
Figura 19 – Diagrama da rotina para enviar bit-a-bit ao TRF-2.4G......................................... 39
Figura 20– Diagrama da rotina para receber dados para o TRF-2.4G ..................................... 40
Figura 21 – Diagrama da rotina para receber bit-a-bit ao TRF-2.4G ....................................... 40
Figura 22 – Diagrama da rotina executada em caso de interrupção......................................... 40
Figura 23 – Diagrama da rotina de configuração ..................................................................... 41
Figura 24 – Diagrama da rotina de mudança para receptor...................................................... 41
Figura 25 – Diagrama da rotina de mudança para transmissor ................................................ 42
Figura 26 – Diagrama da rotina para mandar dados via serial ................................................. 42
Figura 27 – Diagrama de Nassi-Schneiderman do trem........................................................... 43
Figura 28 – Diagrama da rotina de interrupção do trem........................................................... 44
Figura 29 – Diagrama de Nassi-Schneiderman do cruzamento ............................................... 45
Figura 30 – Placa do controlador.............................................................................................. 47
Figura 31 – Ligação original do motor do trem........................................................................ 47
Figura 32 – Ligação da roda com placa e motor do trem ......................................................... 48
Figura 33 – Trem com placas instaladas .................................................................................. 49
Figura 34 – Desvio Frateschi.................................................................................................... 49
Figura 35 – Placa do cruzamento ............................................................................................. 50
Quadro 6 – Método de envio para porta serial ......................................................................... 51
Quadro 7 – Método de recebimento de dados .......................................................................... 52
Quadro 8 – Trecho de código da classe Malha....................................................................... 53
Figura 36 – Comunicação entre as partes envolvidas............................................................... 54
Quadro 9 – Array de bytes para envio de mensagens a dispositivos do tipo trem e cruzamento
............................................................................................................................... 54
Quadro 10 – Array de bytes para recebimento de mensagens pelo controlador....................... 55
Quadro 11 – Métodos para envio de dados .............................................................................. 55
Quadro 12 – Métodos para recebimento de dados ................................................................... 56
Quadro 13 – Laço principal do programa................................................................................. 57
Quadro 14 – Rotina tratadora de interrupção do trem .............................................................. 58
Quadro 15 – Método de aceleração e desaceleração com PWM.............................................. 59
Quadro 16 – Comandos aceitos pelo trem................................................................................ 59
Quadro 17 – Rotina que detecta passagem por sensores .......................................................... 60
Quadro 18 – Métodos para abrir e fechar desvio...................................................................... 60
Quadro 19 – Comandos aceitos pelo cruzamento .................................................................... 61
Figura 37 – Tela inicial do software......................................................................................... 62
Figura 38 – Tela de cadastro de trens ....................................................................................... 62
Figura 39 – Tela de cadastro de cruzamentos........................................................................... 63
Quadro 20 – Características do protótipo desenvolvido e trabalhos correlatos ....................... 64
LISTA DE SIGLAS
API – Application Programming Interface
CBL – Computador de Bordo de Locomotivas
CommAPI – Java Communications API
CRC – Cyclic Redundancy Check
DVD – Digital Versatile Disc
E/S – Entradas e Saídas
EEPROM – Electrically Erasable Programmable Read-Only Memory
GPS – Global Position System
PDAs – Personal Digital Assistants
PWM – Pulse Width Modulation
RAM – Random Access Memory
RF – Requisitos Funcionais
RISC – Reduced Instruction Set Computer
RNF – Requisitos Não-Funcionais
SMD – Surface Mounted Devices
UML – Unified Modeling Language
USB – Universal Serial Bus
WDT – WatchDog Timer
SUMÁRIO
1 INTRODUÇÃO.................................................................................................................. 13
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 14
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 14
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 16
2.1 SISTEMAS DE CONTROLE DE FERROVIAS.............................................................. 16
2.2 MICROCONTROLADORES ........................................................................................... 17
2.2.1 Microcontrolador PIC16F628A ...................................................................................... 18
2.3 SOFTWARE EMBARCADO ........................................................................................... 19
2.4 PWM.................................................................................................................................. 20
2.5 TRANSMISSÃO SEM FIO .............................................................................................. 21
2.6 DETECÇÃO E CORREÇÃO DE ERROS ....................................................................... 22
2.7 COMPONENTE TRF-2.4G .............................................................................................. 23
2.8 RX/TX ............................................................................................................................... 24
2.9 TRABALHOS CORRELATOS........................................................................................ 25
2.9.1 Aplicativo para controle de ferrovia utilizando processamento em tempo real e redes de
Petri ................................................................................................................................. 26
2.9.2 Uma aplicação para controle do tráfego ferroviário usando processos concorrentes ..... 28
2.9.3 Controle computacional de malha ferroviária (Modellbahnanlage der Informatik)....... 28
2.9.4 Considerações sobre os trabalhos correlatos................................................................... 29
3 DESENVOLVIMENTO.................................................................................................... 30
3.1 REQUISITOS DO SISTEMA........................................................................................... 30
3.2 ESPECIFICAÇÃO ............................................................................................................ 30
3.2.1 Visão geral da solução proposta...................................................................................... 31
3.2.2 Hardware ......................................................................................................................... 32
3.2.2.1 Diagrama esquemático do controlador ......................................................................... 32
3.2.2.2 Diagrama esquemático do trem .................................................................................... 33
3.2.2.3 Diagrama esquemático do cruzamento ......................................................................... 34
3.2.3 Software .......................................................................................................................... 35
3.2.3.1 Especificação do controle central ................................................................................. 35
3.2.3.2 Especificação do controlador........................................................................................ 38
3.2.3.3 Especificação do trem................................................................................................... 42
3.2.3.4 Especificação do cruzamento........................................................................................ 44
3.3 IMPLEMENTAÇÃO ........................................................................................................ 45
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 45
3.3.2 Hardware ......................................................................................................................... 46
3.3.2.1 Montagem da placa do controlador .............................................................................. 46
3.3.2.2 Montagem da placa do trem ......................................................................................... 47
3.3.2.3 Montagem da placa do cruzamento .............................................................................. 49
3.3.3 Software .......................................................................................................................... 50
3.3.3.1 Controle central ............................................................................................................ 50
3.3.3.2 Controlador ................................................................................................................... 54
3.3.3.3 Controle trem ................................................................................................................ 57
3.3.3.4 Cruzamento................................................................................................................... 59
3.4 OPERACIONALIDADE DA IMPLEMENTAÇÃO ........................................................ 61
3.5 RESULTADOS E DISCUSSÃO ...................................................................................... 63
4 CONCLUSÕES.................................................................................................................. 65
4.1 EXTENSÕES .................................................................................................................... 65
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 67
13
1 INTRODUÇÃO
Graças a exportação de minério e grãos, como a soja, o Brasil, através da iniciativa
privada em conjunto com o estado, mantém e investe nas ferrovias nacionais. Atualmente, as
estradas de ferro que ligam o interior dos estados aos portos situados no litoral brasileiro são
as que possuem um maior tráfego de trens (VENCOVSKY, 2006, p. 18). Parte deste
investimento está no desenvolvimento de tecnologias, mais precisamente em segurança e
logística.
Segundo Vencovsky (2006, p. 42), o transporte ferroviário têm vantagens sobre os
demais meios, como o aéreo ou rodoviário, tendo principalmente a quantidade de carga a ser
transportada em relação ao baixo valor agregado do produto e ao grande volume a ser
carregado, como por exemplo a soja. Roncarati (1998) acrescenta que “[...] um trem de carga
pode transportar milhares de toneladas de mercadorias através de um continente inteiro [...]”.
Sabendo que trens podem trafegar com grandes quantidades de carga, passando por
cruzamentos ou desvios para conseguirem chegar a seus respectivos destinos, verifica-se que
a ocorrência de acidentes pode trazer conseqüências drásticas. Pessoas podem estar
envolvidas nesses acidentes, sem falar nos possíveis prejuízos da perda de mercadoria ou até
mesmo dos estragos que podem ser causados ao meio ambiente.
Sabendo-se das proporções que acidentes ferroviários podem causar, vê-se necessário
o controle da malha ferroviária. Conforme Janczura (1998, p. 1), um sistema de controle de
uma malha ferroviária torna-se complexo, não podendo ocorrer falhas, sendo importante que
esses sistemas sejam rigorosamente especificados para assegurar que quaisquer erros ou
omissões sejam detectados antes da implementação e implantação.
Um grande problema no transporte ferroviário é fazer o controle de toda a malha
ferroviária manualmente, a qual envolve trens, semáforos, entre outros. [...] Os
sistemas de controle de uma malha ferroviária devem ser desenvolvidos para operar
em tempo real, devido a natureza do problema e a necessidade de constantes
verificações das posições dos trens, das rotas, dos semáforos, entre outros.
(SCHUBERT, 2003, p. 15).
Visto o acima descrito e o fácil acesso da obtenção de uma maquete de uma malha
ferroviária para testes, foi iniciado no ano de 2003 um projeto para automatização da mesma.
Uma implementação, em nível de protótipo, para o controle do tráfego em uma malha
ferroviária foi realizada, a qual está relatada em Schubert (2003). Algumas dificuldades foram
encontradas no projeto, destacando-se o problema detectado na transmissão de dados via rádio
freqüência, devido aos ruídos gerados principalmente pelo motor do trem e a tecnologia
14
usada, a qual não se mostrou apropriada para tratar o caso. Ainda, problemas de controle de
velocidade foram encontrados devido a complexidade de sua implementação no
microcontrolador utilizado (PIC16F84A), pelo fato de não possuir embutido o comando Pulse
Width Modulation (PWM) em hardware, possuindo apenas em software (emulação).
A partir dos problemas encontrados no trabalho relatado em Schubert (2003), propõese solucioná-los através de uma nova construção de um sistema de controle de uma malha
ferroviária, utilizando tecnologias diferentes, como um novo microcontrolador (com software
embarcado) que ofereça novos recursos tais como o PWM em hardware e um novo
componente para transmissão por rádio freqüência. Os testes serão realizados utilizando-se
uma maquete de ferrorama.
1.1
OBJETIVOS DO TRABALHO
O objetivo deste trabalho é a automatização do controle de uma malha ferroviária
utilizando como base o trabalho iniciado por Schubert (2003), através do emprego de
tecnologias diferentes e a inclusão de novas funcionalidades.
Os objetivos específicos do trabalho são:
a) substituir o microcontrolador utilizado (PIC16F84A) pelo PIC16F628A;
b) implementar o controle de velocidade nos trens (aceleração/desaceleração);
c) melhorar a transmissão de dados entre os componentes envolvidos (controlador1,
trens e cruzamentos), utilizando o componente TRF-2.4G;
d) aperfeiçoar o sistema de sensores da ferrovia.
1.2
ESTRUTURA DO TRABALHO
Este trabalho está divido em quatro capítulos. O primeiro traz uma introdução ao
assunto e do que se trata o trabalho. O segundo apresenta uma fundamentação teórica dos
1
Controlador é utilizado no texto para representar o hardware que envia e recebe mensagens aos dispositivos
(trens e cruzamentos).
15
conhecimentos necessários ao desenvolvimento. O terceiro descreve detalhes sobre a
especificação, implementação e testes realizados. O quarto capítulo trata das conclusões e
sugestões para extensões no trabalho.
16
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são apresentados os conceitos necessários ao desenvolvimento deste
trabalho, os quais são: sistema de controle de ferrovias, microcontroladores, software
embarcado, PWM, transmissão sem fio, detecção e correção de erros, o componente TRF2.4G e trabalhos correlatos.
2.1
SISTEMAS DE CONTROLE DE FERROVIAS
Segundo Janczura (1998, p. 6), as sinalizações são muito importantes para o controle
de uma malha ferroviária, tanto para segurança quanto na movimentação dos trens na ferrovia.
O desenvolvimento e a implementação dos primeiros sistemas de sinalização começaram logo
após o surgimento das ferrovias no século 19. Os meios de controle eram primitivos, sendo
que todo o controle do tráfego era realizado por pessoas que ficavam em determinados locais
para fazer a sinalização aos maquinistas. O problema destes sistemas controlados e
sinalizados diretamente por pessoas estavam nas chances de haver falha na interpretação dos
sinais passadas ao maquinista, podendo ocorrer também falhas nas decisões tomadas pelo
operador.
Após esta fase inicial surgiram novos meios para o controle do tráfego, entre eles citase o uso de semáforos. Os semáforos primeiramente manuais, eram difíceis de serem
visualizados pelo maquinista, tornando-os inseguros. Os sinais apresentados pelo semáforo
manual eram compostos por três estados, stop (parado), caution (atenção) e all right (avante,
livre), que foram representados pela posição de um braço, respectivamente nas posições:
horizontal, inclinado para baixo e verticalmente para baixo. Por se tratar de um sistema
mecânico, existia o perigo do semáforo estar quebrado e consequentemente com o braço
verticalmente para baixo, caído (all right), podendo assim indicar um sinal inconsistente. No
período da noite utilizava-se a luz amarela para indicar o estado all right, sendo que nesta
ocasião existia o problema do maquinista confundir a luz com a luz de outro trem que
estivesse estacionado (JANCZURA, 1998, p. 7).
As operações nos semáforos eram baseadas em tempo, por exemplo, depois de um
determinado trem sair da estação, o semáforo era colocado no estado de stop, impossibilitando
17
um segundo trem a sair. Após um espaço de tempo pré-determinado, o semáforo é passado
para o estado caution, possibilitando outro trem a sair da estação. Como o campo de visão do
operador de semáforo era limitado, o mesmo poderia liberar um trem para sair da estação
mesmo tendo acontecido um acidente ou quebra com o primeiro trem, onde poderia ocorrer
uma colisão entre os mesmos.
Conforme Janczura (1998, p. 8), melhoramentos foram acrescentados. Os semáforos
deixaram de ser baseados em tempo e passaram a ser baseados por intervalo de espaço. Nessa
condição, o operador do semáforo só liberava a passagem de outro trem após a confirmação
de chegada ou passagem do outro trem por outro semáforo. Para que isso fosse possível foi
utilizado o telégrafo como meio de comunicação entre os operadores dos semáforos.
Hoje existem diversos tipos de sistemas de sinalizações ao redor do mundo. O
princípio desses sistemas é muito parecido com o descrito anteriormente, mudando
principalmente a forma de comunicação e automatizando as operações dos semáforos,
utilizando meios mais eficientes que o telégrafo.
Dos sistemas atuais destacam-se os que foram desenvolvidos pela empresa América
Latina Logística, os quais são (AMÉRICA LATINA LOGÍSTICA, 2005):
a) Computador de Bordo de Locomotivas (CBL): permite monitorar os trens e
verificar se as autorizações para circulação enviadas pelo centro de controle estão
sendo atendidas;
b) detector de descarrilamento: sistema de monitoramento instalado ao longo da
ferrovia para monitorar o rodado dos trens; se sair dos trilhos é enviado um alerta
para que o trem pare imediatamente, podendo assim evitar um acidente;
c) Global Position System (GPS): através do uso do GPS é possível saber se um
determinado trem está atrasado ou até parado em seu percurso.
2.2
MICROCONTROLADORES
O microcontrolador corresponde a um microprocessador e seus periféricos típicos,
todos juntos num só chip. Os microprocessadores executam operações matemáticas, lógicas,
conversões de analógico para digital, comunicam-se com o mundo exterior através das portas
de entradas e saídas (E/S), PWM, entre outros recursos (ZANCO, 2005, p. 33).
18
Existe uma grande variedade de famílias de microcontroladores, dentre elas
exemplifica-se: MCS51; PIC e HC08. A escolha de um microcontrolador varia muito,
dependendo de suas características.
2.2.1
Microcontrolador PIC16F628A
Os microcontroladores PIC são fabricados pela empresa Microchip Tecnology. Esses
microcontroladores utilizam a arquitetura Reduced Instruction Set Computer (RISC), o que
permite que eles tenham um reduzido número de instruções. Podem operar com freqüências
de até 40MHz (ZANCO, 2005, p. 37).
Conforme Microchip (2005, p. 5), as principais características do microcontrolador
PIC16F628A são (figura 1):
a) 16 pinos de E/S: o desenvolvedor tem a opção de selecionar individualmente cada
pino como entrada ou saída conforme sua necessidade;
b) freqüência de até 20MHz: permite o uso de uma fonte geradora de clock externa,
limitando-se a um clock máximo de 20MHz;
c) oscilador interno de 4MHz/37KHz: com uma precisão menor em relação ao clock
externo, tem a vantagem de não precisar utilizar os pinos RA7 e RA6 para o
cristal externo;
d) 2K bytes de memória FLASH de programa: espaço em memória destinado para
gravação do programa que será executado no microcontrolador;
e) 224 bytes de memória Random Access Memory (RAM) para dados:
disponibilidade de memória volátil para uso do programa. Após um reset os dados
são perdidos;
f) 128 bytes de memória Electrically Erasable Programmable Read-Only Memory
(EEPROM) interna: memória não volátil. O programa tem a possibilidade de
gravar e regravar sem perder os dados após um reset;
g) módulos TIMER 0, TIMER 1 e TIMER 2: estes módulos podem ter função de
temporizadores e ou de contadores;
h) módulo CCP (modos Capture, Compare e PWM): o módulo CCP é um periférico
que pode funcionar de três modos diferentes: capture, utilizado para medir o
tempo entre dois eventos ocorridos no pino RB3/CCP1; compare, compara a todo
19
o instante o conteúdo do par de registradores TMR1H:TMR1L com
CCPR1H:CCPR1L e PWM, modulação por largura de pulso;
i)
dois comparadores analógicos: o comparador é um circuito que compara duas
tensões analógicas;
j)
um canal de comunicação serial: dispõem de um módulo específico para
transmissão de dados serial;
k) WatchDog Timer (WDT): é um temporizador com um oscilador próprio.
Independente do oscilador principal, caso o WDT produza um timeout, provoca
um reset no programa;
l)
tensão de operação entre 2,5 a 5,5v: o microcontrolador pode operar com tensões
entre 2,5 e 5,5 volts;
m) interrupções: o PIC16F628A possui nove fontes de interrupção independentes:
estouro Timer 0; interrupção externa RB0/INT; mudança de estado no pinos
(RB7:RB4); término de escrita na EEPROM; módulo comparador; interrupção de
USART; módulo CCP; estouro Timer 1; interrupção quando Timer 2 igual ao PR2.
Fonte: Microchip (2005, p. 4).
Figura 1 – Pinagem do PIC16F628A
2.3
SOFTWARE EMBARCADO
Segundo Taurion (2005, p. 1-4), “Software embarcado é o software que é embutido em
um equipamento como um sistema de injeção eletrônica de um automóvel, permitindo que
este equipamento atue com maior funcionalidade e flexibilidade”. Exemplos de equipamentos
que possuem software embarcado são: aparelhos de Digital Versatile Disc (DVD), televisores,
20
microondas, aviões e Personal Digital Assistants (PDAs).
Taurion (2005, p. 5) destaca que devido a rápida evolução tecnológica, equipamentos e
dispositivos estarão utilizando cada vez mais software embarcado. A indústria automotiva
pode ser usada como exemplo. Os automóveis atuais pouco evoluíram mecanicamente, mas
em compensação a quantidade de software embarcado aumenta a cada nova funcionalidade
inserida.
O software embarcado diferentemente do software de uso geral limita-se a um número
fixo de tarefas a serem executadas. O caso do software do sistema de injeção eletrônica de um
automóvel é limitado apenas a rodar no hardware especifico para tal função. Em outras
palavras, o software exercerá função de controlador de motor ao longo de toda a sua vida útil
(LOMBARDO, 2002, p. 16).
2.4
PWM
Segundo Barr (2001), PWM é uma técnica avançada para controlar circuitos
analógicos com a saída digital de um microcontrolador. Zanco (2005, p. 236) acrescenta que
PWM é um sinal digital com freqüência fixa, mas com largura de pulso variável. Há uma
variedade de usos e aplicações, destacando-se: medições, comunicação para controle de
potência e principalmente controle analógico. Exemplo de um controle analógico é o botão de
volume de um rádio. Ao girar o botão, é aumentado ou diminuído o fluxo de corrente elétrica,
controlando-se assim o volume.
A figura 2 mostra o sinal digital da saída PWM de um microcontrolador e demonstra
três níveis diferentes. O primeiro valor de saída está a 10% de sua capacidade total, ou seja, o
pulso está em 10% do tempo alto e 90% em baixo. Em seguida estão demonstrados os valores
em 50% e 90%, respectivamente.
21
Fonte: adaptado de Barr (2001).
Figura 2 – Exemplo de saídas do PWM
Ghirardello (2006) conclui que em teoria o PWM em condição de aberto, valor de
saída alto em 0%, nenhuma corrente circula sobre o dispositivo de controle, portanto, sua
dissipação é nula. Na condição de fechado, valor de saída alto em 100%, teoricamente,
apresenta uma resistência nula, sem queda de tensão e dissipação de potência. Na teoria o
controle por PWM não existe nenhum tipo de perda de potência, consistindo em uma solução
ideal para controle de uma saída analógica, como por exemplo o controle da velocidade de um
motor.
2.5
TRANSMISSÃO SEM FIO
Há vários meios de transmissão sem fio, como: rádio freqüência, microondas e
infravermelho. A grande vantagem vem da inexistência de instalações de cabos, a mobilidade
e flexibilidade. As desvantagens de maneira geral é que são mais lentas e têm problemas com
condições ambientais e segurança dos dados transmitidos, já que o meio de propagação pode
ser interceptado por qualquer um (DOYLE; ZACKER, 2000, p. 875).
As ondas de rádio são fáceis de gerar, podem percorrer longas distâncias e podem
passar facilmente paredes de prédios ou casas. A rádio freqüência é amplamente utilizada para
comunicação, seja em locais abertos ou fechados. Estas ondas também são omnidirecionais, o
que significa que elas viajam a todas as direções a partir do transmissor, ou seja, o transmissor
e receptor não precisam estar fisicamente alinhados (TANENBAUM, 2003, p. 109).
Dos tipos de transmissão de pacotes destacam-se: unicast (emissor envia para um
destinatário), multicast (emissor envia para vários destinatários) e broadcast (emissor envia
22
para todos destinatários).
Conforme Tanenbaum (2003, p. 17), em broadcasting é utilizado apenas um canal de
comunicação compartilhado entre todos os equipamentos pertencentes à rede. Pacotes
enviados por qualquer equipamento são recebidos por todos os outros, sendo que dentro do
pacote existe o endereço do equipamento destinatário. Todo equipamento ao receber um
pacote verifica se este o pertence, caso não seja destinado a ele, o pacote será descartado.
Existe também a possibilidade de um pacote ser enviado a todos os equipamentos
pertencentes a rede, sendo que para isto é utilizado um código especial para o endereço do
destinatário.
2.6
DETECÇÃO E CORREÇÃO DE ERROS
Erros de transmissão de dados são relativamente comuns, principalmente em alguns
meios como nas transmissões sem-fios. Como resultado dos processos físicos que os geram,
os erros tendem a acontecer com mais freqüência em grandes volumes (rajadas) do que
separadamente (PÉRICAS, 2003, p. 42).
Existe basicamente duas estratégias para tratar erros. A primeira utiliza códigos de
correção de erros, na qual inclui-se informação redundante suficiente em cada bloco de dados
enviados, onde o receptor pode deduzir qual o dado que está faltando na transmissão. A
segunda utiliza códigos de detecção de erros, na qual se inclui redundância suficiente para
permitir que o receptor deduza que houve um erro, mas sem possibilidade de corrigí-lo,
pedindo assim uma retransmissão.
Uma forma mais simples usada para a detecção de erros é através da utilização de bit
de paridade. Esse bit adicionado ao byte a ser transmitido é escolhido pela quantidade de bits
altos (1) que o byte possui. Quando ocorrer um erro de qualquer bit composto pelo byte
haverá um erro de paridade.
Outra técnica utilizada para a detecção de erros é método polinomial ou também
conhecido como Cyclic Redundancy Check (CRC). Quando o método do CRC é empregado, o
transmissor gera o polinômio e o anexa ao dado a ser transmitido. O receptor pega o dado
recebido e gera o seu polinômio para em seguida compará-lo com o recebido pelo
transmissor. Se os resultados forem iguais o dado está correto.
23
2.7
COMPONENTE TRF-2.4G
O componente TRT-2.4G (transceiver) é um circuito confeccionado por Laipac Tech
(1998) para transmissão de dados sem fio. Seu circuito é composto por antena, sintetizador de
freqüência, amplificador de sinal e possui embutido um cristal para o oscilador. Trabalha na
freqüência de 2.4 GHz, aceita transmissão full-duplex, incluindo codificação, decodificação e
buffer de dados.
O TRF-2.4G tem incorporado a função de CRC para detecção de erros, já tendo
implementado a geração e verificação de CRC (LAIPAC TECH, 2005).
Na figura 3 é mostrado o componente TRF-2.4G e o funcionamento de cada pino do
componente é apresentado no quadro 1.
Fonte: Laipac Tech (2005, p. 4).
Figura 3 – Componente TRF-2.4G
Pino
1
2
3
4
5
6
7
Nome
GND
CE
CLK2
CS
CLK1
DATA
DR1
8
9
DOUT2
DR2
10
VCC
Função
Alimentação
Entrada
E/S
Entrada
E/S
E/S
Saída
Descrição
Terra (0v)
Habilita modo receptor ou transmissor
Entrada de clock receptor canal 2
Habilita modo de configuração
Entrada de clock receptor canal 1
Recepção dos dados canal 1
Indicação de dados para leitura no canal 1
(somente no modo ShockBurst)
E/S
Recepção dos dados canal 2
Saída
Indicação de dados para leitura no canal 2
(somente no modo ShockBurst)
Alimentação Alimentação 3V/DC
Fonte: Laipac Tech (2005, p. 5).
Quadro 1 – Funcionalidade dos pinos do TRF-2.4G
O componente TRF-2.4G pode operar em dois modos: ShockBurst e Direct Mode. O
modo de operação ShockBurst é dividido em duas etapas: o microcontrolador transfere o dado
a ser transmitido ao transceiver; e o transceiver transmite este dado aos demais transceivers
(receptores). Nesta primeira etapa o microcontrolador pode enviar o dado na velocidade em
24
que o desenvolvedor entender mais adequado, normalmente mais lento, permitindo o uso de
microcontroladores com baixa velocidade de processamento. O dado é armazenado no buffer
interno ao transceiver. A segunda etapa consiste em transmitir o dado já armazenado no
buffer aos demais transceivers (receptores) presentes no ambiente, independente do
microcontrolador. Para velocidade de transmissão da segunda etapa é possível escolher entre
250 Kbps e 1 Mbps, configurados no transceiver. Para a recepção do dado pelo
microcontrolador de um receptor, é realizado o processo inverso ao descrito anteriormente.
Na figura 4 é demonstrado o princípio de funcionamento do modo ShockBurst.
Figura 4 – Funcionamento do modo ShockBurst
No modo Direct Mode o transceiver funciona como um transmissor e receptor
convencional, não sendo utilizado nenhum tipo de buffer interno ao componente. Caso desejase transmitir a uma velocidade de 1 Mbps, o microcontrolador precisa enviar o dado ao
transceiver nesta velocidade. Como não utiliza buffer, o dado enviado do microcontrolador ao
componente é diretamente transmitido.
2.8
RX/TX
De acordo com Jarvi (1998), RX/TX é uma Application Programming Interface (API)
para a plataforma Java que oferece suporte a escrita e leitura em portas seriais e paralelas de
computadores. O ponto de maior relevância desta API, em relação a Java Communications
API (CommAPI) da Sun, é a sua portabilidade a vários sistema operacionais, como por
exemplo: Windows, MacOS, Linux, Solares, entre outros. Outro ponto positivo desta
biblioteca é a compatibilidade com a especificação da CommAPI da empresa Sun.
No quadro 2 é apresentado um exemplo de código. Neste exemplo é demonstrada a
maneira de reconhecer as portas existentes do computador. A API fornece o método
getPortIdentifier
que retorna em uma estrutura Enumeration as portas disponíveis. Com
o laço while são adicionadas as portas encontradas no array portas. A variável ips é uma
25
instancia da classe CommPortIdentifier e representa uma porta.
import gnu.io.CommPortIdentifier;
import gnu.io.SerialPort;
.
.
.
Enumeration listaDePortas;
listaDePortas = CommPortIdentifier.getPortIdentifiers();
.
.
.
int i = 0;
portas = new String[10];
while (listaDePortas.hasMoreElements()) {
CommPortIdentifier ips = CommPortIdentifier)listaDePortas.nextElement();
portas[i] = ips.getName();
i++;
}
.
.
.
Fonte: adaptado de Jarvi (1998).
Quadro 2 – Exemplo de código utilizando classe da API RX/TX
Para o envio de dados (quadro 3) para porta serial é necessário abrir a porta, passar os
parâmetros da porta, criar um fluxo de saída e escrever os dados na porta.
...
//identificar a porta
CommIdentifier cp = CommPortIdentifier.getPortIdentifier(PortaEscolhida);
//abrir a porta a serial
SerialPort porta = (SerialPort)cp.open("NomeDaClasse",timeout);
//setar parâmetros de configuração da porta
porta.setSerialPortParams(baudrate, DATABITS_8, STOPBITS_2, PARITY_NONE);
//atribuir fluxo de saída para classe abstrata de saída de dados
OutputStream saida = porta.getOutputStream();
//escrever na porta serial
String msg = “Olá Mundo!”;
saida.write(msg.getBytes());
saida.flush();
...
Fonte: adaptado de Jarvi (1998).
Quadro 3 – Exemplo de código utilizado para enviar bytes
2.9
TRABALHOS CORRELATOS
A seguir são explanados três trabalhos correlatos desenvolvidos, apresentados em
26
Shubert (2003), Raulino (1999) e Kluge (1999).
2.9.1
Aplicativo para controle de ferrovia utilizando processamento em tempo real e redes
de Petri
Schubert (2003) construiu um protótipo de uma malha ferroviária (figura 5) utilizando
uma maquete para testes. O foco de seu trabalho era a utilização de Redes de Petri para fazer a
especificação do controle de uma malha ferroviária. O sistema visava o controle em tempo
real de trens. O trabalho teve problemas com a comunicação por rádio freqüência, devido a
ruídos gerados pelo motor do trem. O microcontrolador utilizado para controle dos trens era o
PIC16F84A, o qual não possibilitava a utilização de PWM em hardware para a aceleração e
desaceleração destes.
Fonte: Schubert (2003, p. 73).
Figura 5 – Visão geral da maquete
A alimentação do circuito do trem (figura 6) foi feita através de pilha, isolada da
alimentação do motor, a qual era feita através dos trilhos energizados. Tal configuração foi
arquitetada objetivando a diminuição de interferências geradas pelos ruídos causados pelo
motor do trem.
27
Fonte: Schubert (2003, p. 73).
Figura 6 – Visão do trem desenvolvido por Schubert (2003)
Antes dos cruzamentos haviam sensores que indicavam suas presenças ao circuito do
trem. As mudanças de direção dos desvios dos cruzamentos não foram automatizados, sendo
realizados de forma manual quando necessário (figura 7).
Fonte: Schubert (2003, p. 73).
Figura 7 – Visão do cruzamento desenvolvido por Schubert (2003)
28
2.9.2
Uma aplicação para controle do tráfego ferroviário usando processos concorrentes
Raulino (1999) teve como objetivo mostrar a especificação e implementação de um
protótipo para o controle de uma malha ferroviária. Utilizou em seu trabalho para a
modelagem do protótipo, um modelo formal de especificação e controle de fluxo, chamado de
Redes de Petri. Para a implementação do protótipo foi usada a linguagem de programação
Ada. Processos concorrentes foram utilizados no sistema. Nenhuma implementação em
hardware foi realizada neste trabalho, apenas simulações em software (figura 8).
Fonte: Raulino (1999, p. 76).
Figura 8 – Interface de execução da aplicação desenvolvida por Raulino
2.9.3
Controle computacional de malha ferroviária (Modellbahnanlage der Informatik)
Em Kluge (1999) é relata a construção de uma maquete de malha ferroviária. A
maquete é utilizada para aulas de graduação para o ensino de Redes de Petri, software
embarcado e programação em tempo real. Seu foco é mostrar o comportamento e organização
dos trens na malha, como também ocorrências de concorrência, conflitos e deadlocks e a
solução destes problemas. Na implementação do software foi utilizada a linguagem de
programação C e C++, sendo executado em plataforma Unix. Praticamente todo o hardware
do projeto foi desenvolvido exclusivamente para a maquete, que inclui fontes de alimentação
dos trens e controladores, placas de comunicação entre computador e controladores, sensores
29
para os trilhos (figura 9) e cabo para comunicação. A malha desenvolvida por Kluge (1999)
foi dividida em trechos (seguimentos de trilhos). Estes trechos são eletricamente separados
entre si, sendo que para acionar um trem é energizado o trecho em que o mesmo encontra-se.
Fonte: Kluge (1999).
Figura 9 – Utilização de reed-switch como sensores
2.9.4
Considerações sobre os trabalhos correlatos
No quadro 4 são apresentadas características sobre os trabalhos de Schubert (2003),
Raulino (1999) e Kluge (1999).
Características
Redes de Petri
Schubert (2003)
Raulino (1999)
Kluge (1999)
Processos concorrentes
Implementação em
hardware
Rádio freqüência
Alimentação dos motores
Trilhos
dos trens
Alimentação do circuito
Pilhas
dos trens
Sensores para detecção da
posição dos trens
Cruzamentos com opção
de desvio automatizado
PWM para aceleração dos
trens
Linguagem de
Delphi
Ada
programação
Quadro 4 – Características dos trabalhos correlatos
Trilhos
C++
30
3 DESENVOLVIMENTO
Nas próximas seções são apresentados os requisitos do sistema, a especificação do
hardware e software, a implementação, a operacionalidade da implementação, os resultados e
discussão e a conclusão.
3.1
REQUISITOS DO SISTEMA
Os Requisitos Funcionais (RF) e Requisitos Não-Funcionais (RNF) do sistema, são:
a) controle de velocidade nos trens (RF);
b) comunicação broadcast entre os trens, os cruzamentos e o controlador (RF);
c) verificação dos pacotes transmitidos via RF com CRC (RF);
d) uso do microcontrolador PIC16F628A (RNF);
e) uso do circuito TRF-2.4G (RNF);
f) uso de uma maquete para testes, objetivando simular o mundo real (RNF);
g) uso da linguagem Java para programação do controle no PC (RNF);
h) uso da linguagem C para programação dos microcontroladores (RNF).
3.2
ESPECIFICAÇÃO
O sistema desenvolvido visa controlar um protótipo de uma malha ferroviária. Para tal
foi utilizado um ferrorama, assim como foram desenvolvidos circuitos eletrônicos e software
embarcado para comunicar e controlar dispositivos externos ao computador, como os trens e
cruzamentos.
No computador foram implementadas as rotinas de envio e recebimento de mensagens
aos dispositivos externos, a interface com o usuário e o controle central que vai fazer o
gerenciamento da malha. A comunicação entre o computador e os dispositivos externos (trens
e cruzamentos) é feita através de mensagens enviadas via porta serial.
Para cada dispositivo foi feita uma modelagem individual de hardware e software
31
(exceto controle central, no qual só foi feita a parte do software). O sistema está dividido em
controle central, controlador, trens e cruzamentos, os quais serão detalhados adiante.
3.2.1
Visão geral da solução proposta
Para a construção da malha ferroviária foram utilizados componentes da empresa
Frateschi (2007). Estes componentes são: trilhos, trens e cruzamentos. O hardware foi
montado de maneira artesanal, com o auxílio de placas padrão para confecção dos circuitos,
os quais são responsáveis pelo controle da locomoção dos trens, da detecção de sensores, do
posicionamento de cruzamentos e comunicação entre controlador-trem e controladorcruzamento. Nestes circuitos está presente o microcontrolador PIC16F628A, o qual tem a
função de interpretar e executar comandos recebidos através de mensagens enviadas pelo
computador. Além do microcontrolador, existe em cada dispositivo o componente TRF-2.4G,
que é o responsável por fazer a comunicação entre todos os dispositivos envolvidos na malha.
Por fim, existe o controlador que é o hardware que recebe e envia as mensagens aos trens e
cruzamentos. Este hardware está conectado via porta serial ao computador, o qual possui o
software que gerencia a malha.
Na figura 10 é ilustrada a interligação dos componentes do sistema. Caso o trem passe
por um sensor no trilho, encaminhará via rádio freqüência uma mensagem de passagem por
sensores ao controlador, o qual repassará a informação via porta serial ao sistema de controle
central. O mesmo procedimento ocorre no cruzamento. Com base nas informações recebidas,
o sistema de controle central encaminhará comandos para serem executados. Estes comandos
são enviados para o controlador via porta serial, e então via rádio freqüência para trens e
cruzamentos.
32
Figura 10 – Ligação entre componentes do sistema
3.2.2
Hardware
Os diagramas esquemáticos do hardware envolvido no sistema estão descritos nas
subseções seguintes. Para a confecção dos diagramas esquemáticos foi utilizada a ferramenta
de desenho e simulação Proteus (JAMESON, 2006).
3.2.2.1
Diagrama esquemático do controlador
A placa desenvolvida tem o intuito de fazer a ponte de comunicação entre o
computador e os demais dispositivos. Para realizar a comunicação o computador envia
mensagens para a porta serial no padrão RS232. Como o microcontrolador utiliza o padrão de
comunicação TTL, fez-se necessário o uso do componente RS232 para fazer a conversão
entre os padrões. Na interligação entre o componente TRF-2.4G com o microcontrolador,
foram utilizados resistores de 220 Ohms, devido a diferença da tensão de operação destes
componentes, que são respectivamente 3 e 5 volts. Para estabilizar a tensão do circuito em 5
volts fez-se o uso do regulador L7805. O diagrama esquemático da placa do controlador está
representada na figura 11.
33
Figura 11 – Diagrama esquemático do controlador
3.2.2.2
Diagrama esquemático do trem
A figura 12 apresenta o diagrama esquemático do trem. O diagrama foi dividido em
quatro partes para facilitar o entendimento. A área 1 é responsável pela comunicação do trem,
que para tal foi usado o componente TRF-2.4G. Para a detecção de marcações magnéticas
(imãs) nos trilhos, o trem possui em seu circuito um reed-switch (área 2), que ao ser acionado
muda o valor lógico do pino RB7, sendo assim identificado pelo software como a passagem
pelo sensor. O pino RA1 do microcontrolador é destinado a acionar o relé que inverte o
sentido de rotação do motor. O sinal de saída do pino é de baixa corrente, fazendo com que
seja necessária a utilização de um transistor para fazer o acionamento do relé (área 3). Para a
aceleração e desaceleração do motor utilizou-se a saída PWM disponível no microcontrolador
(PIC16F628A). Na área 4 do esquemático é demonstrada a amplificação do sinal PWM,
gerado pelo microcontrolador, para acionar (movimentar) o motor.
34
Figura 12 – Diagrama esquemático do trem
3.2.2.3
Diagrama esquemático do cruzamento
Para controlar o cruzamento foi desenvolvida uma placa (figura 13) que aciona o
desvio e faz a leitura de três sensores do trilho (reed-switch). O acionamento do desvio é
realizado com a magnetização de uma bobina instalada nos trilhos do cruzamento. Com a
utilização de relés é possível a inversão na polarização, possibilitando o fechamento e a
abertura do desvio. O circuito conta com o microcontrolador PIC16F628A e o componente
TRF-2.4G para comunicação via rádio freqüência.
35
Figura 13 – Diagrama esquemático do cruzamento
3.2.3
Software
Nas
subseções
seguintes
são
apresentados
os
diagramas
relacionados
ao
desenvolvimento do software envolvido no sistema. Para a especificação do software do
controle central é utilizada a Unified Modeling Language (UML), com auxílio da ferramenta
Enterprise Architect (SPARX, 2007), através de diagramas de casos de uso e de classes. Para
a especificação do software embarcado (controlador, trem e cruzamento) foi utilizado o
diagrama de Nassi-Schneiderman com o auxílio da ferramenta NSD-Editor (KALT, 1997).
3.2.3.1
Especificação do controle central
Controle central é o software contido no computador que faz o controle total de cada
dispositivo pertencente a malha ferroviária. As mensagens recebidas e enviadas via rádio
freqüência aos dispositivos são processadas neste software. Cabe ao software gerenciar a
posição de cada trem, evitando possíveis colisões, e o posicionamento dos desvios dos
cruzamentos.
Ao usuário do sistema estão disponíveis as funções de cadastrar trens e cruzamentos,
36
iniciar o controle da malha, fazendo com que os trens e cruzamentos sejam gerenciados pelo
software, e parar o controle da malha. O diagrama de casos de uso é apresentado na figura 14.
Figura 14 – Diagrama de casos de uso
A figura 15 mostra o diagrama de classes do protótipo do controle central.
Figura 15 – Diagrama de classes
37
A classe Malha é criada para armazenar as informações de ligações entre trechos e
cruzamentos e também conta com instâncias dos objetos Trem. Cada objeto de Trem é um
processo, o qual tem sua execução independente para cada objeto. Nesta execução é
processada a rota já definida em que o trem deverá seguir na malha. No objeto de Cruzamento
tem-se o estado atual do desvio, se está aberto ou fechado. Trecho e Ponto são classes que
demarcam regiões na malha. Os objetos instanciados destas classes possuem controle de
mútua exclusão, pois são considerados recursos e são disputados pelos objetos do tipo Trem.
Os objetos do tipo Sensor são utilizados para saber os pontos de início e fim dos trechos e
pontos, e assim saber a qual trecho está ligado a qual ponto.
A comunicação é realizada pela classe Comunicacao, que se responsabiliza por receber
e enviar mensagens aos dispositivos. É tarefa deste objeto a retransmissão de mensagens e
aguardo de respostas de dispositivos.
Na figura 16 é mostrado como foi modelada a malha do protótipo. Os trechos da malha
foram chamados de T01, T02 e T03. Cada trecho é delimitado por sensores que são
representados por S01 até S06. P01 e P02 são regiões onde existe o cruzamento dos trilhos.
Figura 16 – Modelagem da malha do protótipo
No quadro 4 é demonstrado como foi representado os dados fornecidos pela figura 16.
Todo trecho é delimitado por dois sensores. Tornando-se isso uma regra, sabe-se que do
sensor S01 até o S05 é composto o trecho T01, do S03 até o S06 o trecho T02 e do S02 até o
S04 o trecho T03 (quadro 5).
38
Trechos da malha
T01
S01
S05
T02
S03
S06
T03
S02
S04
P01
S02
S01-S03
P02
S04
S05-S06
Pontos da malha
Quadro 5 – Representação da modelagem da malha representada na fig. 16
Os pontos (P01 e P02) do quadro 5, além de identificarem os sensores os quais estão
relacionados, informam o sentido o qual é possível fazer o desvio. Caso um trem atinja o
sensor S02 do ponto P01, é possível afirmar que o trem poderá (dependendo de sua rota)
escolher se irá passar pelo sensor S01 ou S03. No caso contrário, se o trem detectar os
sensores S01 ou S03 do ponto P01, é obrigatória a passagem pelo sensor S02, não tendo
escolha.
3.2.3.2
Especificação do controlador
O software do controlador tem o papel de encaminhar as mensagens recebidas de uma
ponta para outra (de um lado o computador, ligado via porta serial, e do outro lado os trens e
cruzamentos, ligados via rádio freqüência). Na figura 17 é ilustrado o diagrama geral do
software controlador. As duas formas de receber mensagens são: via porta serial e via rádio
freqüência. Se o controlador recebe via rádio freqüência uma mensagem, irá encaminhá-la
para porta serial. O inverso também é verdadeiro, caso receba via porta serial encaminhará via
rádio freqüência. Para cada byte enviado do computador ao controlador é gerada uma
interrupção no microcontrolador. A rotina tratadora da interrupção é a responsável por
armazenar estes bytes recebidos em um buffer. Quando o buffer está preenchido, indica que
existe uma mensagem pronta para ser enviada via rádio freqüência. Cabe ao software enviar
(figura 18) o buffer bit-a-bit (figura 19) para o componente TRF-2.4G. Caso o componente
tenha dados em seu buffer interno, indica que recebeu uma mensagem via rádio, sendo que o
software irá retirar (figura 20) bit-a-bit (figura 21) para posteriormente enviá-lo para o
computador.
39
Figura 17 – Diagrama de Nassi-Schneiderman do controlador
Figura 18 – Diagrama da rotina para enviar dados para o TRF-2.4G
Figura 19 – Diagrama da rotina para enviar bit-a-bit ao TRF-2.4G
40
Figura 20– Diagrama da rotina para receber dados para o TRF-2.4G
Figura 21 – Diagrama da rotina para receber bit-a-bit ao TRF-2.4G
No início do diagrama do controlador está sendo atribuído o endereço de uma rotina
(figura 22) para ser executada caso ocorra uma interrupção. Esta interrupção ocorerá toda vez
em que o microcontrolador receber dados pela porta serial.
Figura 22 – Diagrama da rotina executada em caso de interrupção
Configurações do transceiver como endereço e velocidade de comunicação, potência
da antena, a habilitação do uso de CRC e o canal de comunicação são apresentados na figura
23.
41
Figura 23 – Diagrama da rotina de configuração
As rotinas para realizar a mudança do transceiver em receptor (figura 24) e para
transmissor (figura 25) são demonstradas nos diagramas das respectivas figuras.
Figura 24 – Diagrama da rotina de mudança para receptor
42
Figura 25 – Diagrama da rotina de mudança para transmissor
Na figura 26 é apresentada a rotina para enviar o dado recebido via rádio para porta
serial.
Figura 26 – Diagrama da rotina para mandar dados via serial
3.2.3.3
Especificação do trem
O software embarcado no trem não possui autonomia de decidir sobre a locomoção e
direção do trem. Decisões sobre a locomoção do trem são de responsabilidade do software
que gerencia a malha no computador. Cabe ao software do trem receber via rádio freqüência
os comandos enviados a ele pelo controle central, os quais são: aceleração e desaceleração na
velocidade desejada, parada total e inversão do motor.
Na figura 27 é ilustrado o diagrama do programa embarcado no trem. No laço principal
do programa testa-se a existência de mensagens disponíveis no TRF-2.4G. Caso tenha
mensagem, é verificado se a mesma pertence ao trem. Se pertencer, será analisado se este
comando já foi executado, evitando que o mesmo comando seja executado mais de uma vez
43
(caso seja uma retransmissão). Após a execução do comando, é enviada uma resposta de
confirmação do recebimento ao computador. Outro teste realizado no laço refere-se ao sensor
magnético presente no trilho. Existe um flag de passagem pelo trilho. Caso estiver ativo, o
software irá informar ao computador a passagem pelo sensor. Neste momento o software
aguarda uma resposta do computador por um tempo determinado. No caso de não receber
uma resposta dentro do tempo determinado, é executada a rotina de parada imediata do trem,
garantindo assim que o mesmo não avance sobre um trecho não autorizado da malha. O flag é
ativado dentro da rotina de tratamento da interrupção. Ainda no laço é verificado se existem
dados para serem enviados por rádio freqüência para o computador.
Figura 27 – Diagrama de Nassi-Schneiderman do trem
No inicio do diagrama do trem (figura 27) está sendo atribuída uma rotina (figura 28)
para ser executada caso ocorra uma detecção de um sensor (rotina atribuída a partir de uma
interrupção). Sempre que o trem passar sobre um sensor do trilho ocorrerá uma interrupção.
44
Figura 28 – Diagrama da rotina de interrupção do trem
3.2.3.4
Especificação do cruzamento
O software do cruzamento tem o papel de chaveador do desvio. Sempre que solicitado
pode alterar o posicionamento dos trilhos, mudando assim o destino do trem que passar no
cruzamento. Além de desviar os trens, é tarefa do cruzamento informar ao controle central a
chegada de trens neste cruzamento. Sempre que um sensor for acionado, o software entrará
em uma rotina de tratamento de interrupção, na qual será ativado um flag do sensor
correspondente. Durante a execução do laço principal do programa, é verificado se existem
flags de sensores ativados. Caso tenha, são enviadas mensagens ao controle central avisandoo dos respectivos sensores. O diagrama da especificação do software do cruzamento é
demonstrado na figura 29.
45
Figura 29 – Diagrama de Nassi-Schneiderman do cruzamento
No começo do diagrama apresentado na figura 29 é atribuída uma rotina para ser
executada caso ocorra uma interrupção.
3.3
IMPLEMENTAÇÃO
A seguir é apresentada a implementação, mostrando as técnicas e ferramentas
utilizadas na confecção do hardware e software.
3.3.1
Técnicas e ferramentas utilizadas
Para implementação do hardware foram utilizados os componentes TRF-2.4G para
comunicação de dados e o microcontrolador PIC16F628A. Para implementação do software
46
no computador foi utilizada a linguagem Java com o ambiente de desenvolvimento Eclipse,
usando a programação orientada a objetos conforme a especificação no diagrama de classes
(figura 15). Para o software embarcado nos microcontroladores foi utilizada a linguagem C,
com o ambiente PIC C, usando a programação estruturada, conforme especificação através
dos diagramas de Nassi-Schneiderman.
3.3.2
Hardware
O hardware corresponde as placas desenvolvidas para controlar trens, cruzamentos e a
comunicação entre os dispositivos com o computador. Nas subseções seguintes é apresentada
a montagem de cada placa, conforme diagramas esquemáticos descritos na especificação.
3.3.2.1
Montagem da placa do controlador
O circuito foi montado em uma única placa (figura 30), conforme diagrama
esquemático apresentado na figura 11. Utilizou-se uma placa do tipo universal para fixação
dos componentes. A fonte de alimentação ficou externa a placa. Para estabilizar a tensão do
circuito em 5 volts fez-se o uso do regulador L7805. Para gerar o clock do microcontrolador
foi utilizado um cristal de 4Mhz.
O componente que tem destaque nesta placa em relação as demais placas (placas do
trem e cruzamento) desenvolvidas no protótipo é o MAX232N, o qual tem a função de
converter sinais do padrão RS232 (usado no computador) para o TTL (usado no
microcontrolador).
47
Figura 30 – Placa do controlador
3.3.2.2
Montagem da placa do trem
A montagem do trem consistiu na modificação de uma locomotiva de ferrorama,
modelo G12 fabricado pela empresa Frateschi (2007). Originalmente os pólos de ligação do
motor estavam ligados indiretamente aos trilhos, através de fios com uma escova de contato
encostada às rodas. Como as rodas e os trilhos são metálicos, a corrente elétrica chega até o
motor (figura 31). Neste modelo existe um controlador (variador de tensão) que libera mais ou
menos energia nos trilhos, fazendo assim com que todos os trens contidos nos trilhos possam
alterar suas velocidades. Desta forma original, torna-se impossível a possibilidade de parar
um trem em um cruzamento e fazer com que outro trem sobre a mesma malha continuasse
andando. Para solucionar este problema teve-se de modificar os trens.
Figura 31 – Ligação original do motor do trem
48
Determinou-se que a alimentação dos trens continuasse vindo dos trilhos, sendo que a
tensão foi fixada em 12 volts. Caso um trem no modelo original fosse colocado nos trilhos
nesta situação, iria andar em velocidade máxima. A primeira modificação feita foi o
desligamento do motor com os fios vindos das rodas. Os fios foram então ligados ao circuito
(placa) confeccionado para controlar o trem. Com isso, o circuito é alimentado com a tensão
que vem dos trilhos. Em seguida o motor foi ligado ao circuito, possibilitando o controle da
velocidade e do sentido de rotação do mesmo. A figura 32 mostra a modificação na ligação do
trem.
Figura 32 – Ligação da roda com placa e motor do trem
A placa controladora do trem, construída conforme diagrama esquemático apresentado
na figura 12, foi instalada sobre a carenagem do mesmo, devido a falta de espaço entre o
motor e a carenagem. Mesmo ficando do lado de fora, a largura da placa não ultrapassou a
largura do trem. Na montagem da placa não foi possível instalar o componente TRF-2.4G
junto à mesma. Devido a isso, fez-se a confecção de duas placas, uma para abrigar o
transmissor e outra para os demais componentes. Um mini-relé duplo foi utilizado para
realizar a inversão do motor. A instalação do reed-switch foi feita no chassi do trem, logo
abaixo do motor.
Após alguns testes verificou-se a presença de ruídos gerados pelo motor. Para
amenizar o nível destes ruídos sobre o circuito, foram trocados os fios de ligação originais do
trem. Os fios foram substituídos por cabos coaxiais e aterrados para evitar interferências
eletromagnéticas. Foi utilizada a malha externa ao cabo para fazer o aterramento. Usou-se
capacitores para resolver possíveis problemas de desligamentos momentâneos entre as rodas e
os trilhos (devido a vibrações).
Na figura 33 é mostrada a placa instalada ao trem.
49
Figura 33 – Trem com placas instaladas
3.3.2.3
Montagem da placa do cruzamento
Os cruzamentos do protótipo são desvios fabricados pela empresa Frateschi (2007).
Estes desvios, ao contrário dos trens, não precisaram sofrer modificações em suas partes
elétricas. A base de funcionamento destes desvios é o eletromagnetismo. Cada desvio possui
uma bobina que tem a função de um eletroímã, que por sua vez, ao ser energizado polariza
(magneticamente) e faz a mudança nos trilhos. Para voltar a posição inicial dos trilhos é
necessário inverter os pólos positivo com o negativo e energizar novamente a bobina. A figura
34 ilustra o desvio utilizado no desenvolvimento do trabalho.
Figura 34 – Desvio Frateschi
O acionamento da bobina do desvio é acionada através de relés, permitindo uma
50
passagem maior de corrente elétrica. Para evitar o aquecimento e uma possível queima das
bobinas, o microcontrolador aciona a bobina por um curto intervalo de tempo, o suficiente
para fazer a mudança dos trilhos, e então a desliga.
A placa do cruzamento (figura 35), confeccionada a partir do diagrama esquemático
apresentado na figura 13, além de ter a função de mudança dos desvios tem a função de
monitorar sensores (reed-switch) nos trilhos. Os sensores são acionados sempre que um trem
passa sobre eles.
Figura 35 – Placa do cruzamento
3.3.3
Software
As implementações dos softwares envolvidos no sistema são apresentados nas
subseções seguintes, seguindo a especificação apresentadas nas figuras 15, e 17 a 29.
3.3.3.1
Controle central
Conforme mencionado na especificação (figura 15), a classe Comunicacao é
responsável pela comunicação entre o controlador e o software controle central. Cabe a classe
o envio e recebimento de mensagens. Toda mensagem enviada para um dispositivo recebe um
51
número que identifica e a torna única. Esta identificação é utilizada para garantir que um
dispositivo não execute mais de uma vez a mesma mensagem. Esta situação poderá ocorrer
caso o dispositivo receba a mensagem e não comunique o recebimento ao controle central,
fazendo com que haja uma retransmissão da mensagem.
As mensagens enviadas ao controlador precisam ser convertidas para um array de 6
bytes. No quadro 6 é apresentado método para o envio de mensagens ao controlador.
private void EnviarUmByte(int[] it) {
if (escrever == true) {
try {
saidaStream = sPorta.getOutputStream();
} catch (Exception e) {
e.printStackTrace();
}
try {
//montar o byte para ser enviado
byte[] bt = new byte[6];
bt[0] = (byte)it[0]; //id do dispositivo
bt[1] = (byte)it[1]; //função
bt[2] = (byte)it[2]; //valor1 funcao
bt[3] = (byte)it[3]; //valor2 funcao
bt[4] = (byte)it[4]; //núm. id da msg
bt[5] = (byte)it[5]; //livre
//escreve array na porta
saidaStream.write(bt);
Thread.sleep(100);
saidaStream.flush();
} catch (Exception e) {
System.out.println("Houve um erro durante o envio.");
e.printStackTrace();
System.exit(1);
}
} else
System.exit(1);
}
Quadro 6 – Método de envio para porta serial
O processo de receber mensagem é implementado utilizando-se um evento (listener)
para os dados recebidos pela porta serial. O método (serialEvent(SerialPortEvent ev))
que trata o evento verifica a quantidade de bytes recebidos e com estes é preenchido um array
de 6 bytes (itBuffer[iBuff]). Ao completar o array, a mensagem foi totalmente recebida e
então é armazenada em um ArrayList chamado resp. O método é apresentado no quadro 7.
52
public void serialEvent(SerialPortEvent ev) {
String dados = null;
switch (ev.getEventType()) {
case SerialPortEvent.BI:
case SerialPortEvent.OE:
case SerialPortEvent.FE:
case SerialPortEvent.PE:
case SerialPortEvent.CD:
case SerialPortEvent.CTS:
case SerialPortEvent.DSR:
case SerialPortEvent.RI:
case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
break;
case SerialPortEvent.DATA_AVAILABLE:
byte[] bufferler = new byte[6];
try {
while (entradaStream.available() > 0) {
nodeBytes = entradaStream.read(bufferler);
}
String dadosLidos = new String(bufferler);
dados = dadosLidos;
} catch (Exception e) {
e.printStackTrace();
}
for (int i = 0; i < nodeBytes; i++) {
if (dados.substring(i, i + 1).getBytes()[0] == '+') {
// nova array de bytes(buffer)
itBuffer = new int[6];
iBuff = 0;
} else if (dados.substring(i, i + 1).getBytes()[0] == '-') {
// finalizou array de bytes(buffer)
// encaminhar para fila de respostas
synchronized (resp) {
resp.getMensagens().add(itBuffer);
}
} else {
// caracteres para formar o buffer
if (iBuff < 6) {
int b = (dados.substring(i, i + 1).getBytes())[0];
if (b < 0)
b = (256 + b);
itBuffer[iBuff] = b;
iBuff++;
}
}
}
break;
}
}
Quadro 7 – Método de recebimento de dados
Na classe Malha foram criadas listas para o armazenamento dos componentes da
malha. O quadro 8 apresenta as declarações das listas de trechos, pontos, sensores,
cruzamentos e trens. Foram implementados nessa classe os métodos de pesquisa para essas
listas. Dos métodos de pesquisa destaca-se o PesquisaTrechoSeguinte(Trem t, Sensor
s).
Nesse método é informado o trem e um sensor acionado por ele (com estas informações
pesquisa-se o trecho seguinte ao trecho atual do trem).
53
Public class Malha {
//lista dos com os objetos de trens cadastrados no sistema
private ArrayList listaTrens = new ArrayList();
//lista dos com os objetos de cruzamentos cadastrados no sistema
private ArrayList listaCruzamentos = new ArrayList();
//lista dos com os objetos de trechos que compõem a malha ferroviária
private ArrayList trechosMalha = new ArrayList();
//lista dos com os objetos de sensores que compõem a malha ferroviária
private ArrayList sensoresMalha = new ArrayList();
//lista dos com os objetos de pontos que compõem a malha ferroviária
private ArrayList pontosMalha = new ArrayList();
//lista das mensagens recebidas e que precisam ser processadas
private CmdMensagens mensagensRecebidas = new CmdMensagens();
...
public boolean PesquisaTrechoSeguinte(Trem t, Sensor s){
boolean retorno = false;
ArrayList tSeguintesTemp = new ArrayList();
Trecho trechoAtual = t.getTrechoAtual();
for (int i=0; i<trechosMalha.size(); i++){
if (!((Trecho)trechosMalha.get(i)).equals(trechoAtual)){
Trecho trechoTemp = (Trecho)trechosMalha.get(i);
if (trechoTemp.getSensor1().equals(s)){
tSeguintesTemp.add(trechoTemp); //achou trecho seguinte
retorno = true;
} else if (trechoTemp.getSensor2().equals(s)){
tSeguintesTemp.add(trechoTemp); //achou trecho seguinte
retorno = true;
}
}
}
for (int i=0; i<pontosMalha.size(); i++){
Ponto pontoTemp = (Ponto)pontosMalha.get(i);
if (pontoTemp.getSensor1().equals(s)){
pontoSeguinte = pontoTemp; //ponto seguinte tem opção de desvio
for (int y=0; y<pontoTemp.getSensoresDesvio().size(); y++){
Sensor sensorTemp = (Sensor)pontoTemp.getSensoresDesvio().get(y);
tSeguintesTemp.add(ProcuraTrecho(sensorTemp));
}
retorno = true;
} else //ponto sem opção de desvio
for (int y=0; y<pontoTemp.getSensoresDesvio().size(); y++){
Sensor sensorTemp = (Sensor)pontoTemp.getSensoresDesvio().get(y);
if (sensorTemp.equals(s)){
pontoSeguinte = pontoTemp;
tSeguintesTemp.add(ProcuraTrecho(pontoTemp.getSensor1()));
retorno = true;
}
}
}
trechosSeguintes = tSeguintesTemp;
return retorno;
}
Quadro 8 – Trecho de código da classe Malha
54
3.3.3.2
Controlador
O software controlador (especificado na figura 17) tem por finalidade detectar
mensagens recebidas dos dispositivos via rádio e encaminhá-las via porta serial para o
computador e vice-versa (receber do computador e enviá-las ao dispositivo endereçado)
(figura 36). Para a tarefa de comunicação por rádio freqüência foi utilizado o componente
TRF-2.4G.
Figura 36 – Comunicação entre as partes envolvidas
Toda mensagem enviada e recebida é composta por um array de seis bytes. Cada byte
tem uma função especifica. No array de envio (quadro 9) a dispositivos (do tipo trem e
cruzamento), o byte [idDisp] é responsável por armazenar o identificador do dispositivo
destino da mensagem. O comando a ser executado no microcontrolador é armazenado no byte
[funcao]. Dependendo da função (comando) a ser executada, é necessário a passagem de
valores (parâmetros), sendo que para tal estão disponíveis os bytes [valor1] e [valor2].
Cada mensagem enviada pelo controle central para os dispositivos possui um número de
identificação. Esta identificação é armazenada no byte [numPacEnv]. Caso a contagem do
byte [numPacEnv] chegar a 255, é reiniciado do número 0. Para o último byte [X] do array
não foi implementada nenhuma função, ficando este disponível.
[idDisp][funcao][valor1][valor2][numPacEnv][X]
Quadro 9 – Array de bytes para envio de mensagens a dispositivos do tipo trem e cruzamento
As mudanças do array de envio para o de recebimento de mensagens são poucas. O
byte [0] representa que a mensagem é destinada ao software de controle central.
[idDispRem]
é o identificador do dispositivo remetente (trens ou cruzamentos). Os demais
55
bytes são conforme descritos anteriormente. As mensagens encaminhadas dos dispositivos ao
controlador têm seu array demonstrado no quadro 10.
[0][idDispRem][funcao][valor1][valor2][numPacEnv]
Quadro 10 – Array de bytes para recebimento de mensagens pelo controlador
Estando o array de envio preenchido, cabe ao software do microcontrolador
encaminhá-lo para o componente TRF-2.4G. O primeiro passo é percorrer o array de bytes,
denominado de buf, para retirar cada byte a ser enviado. O segundo passo é colocar bit-a-bit
no transmissor cada byte a ser enviado. O código responsável pelas operações descritas é
mostrado no quadro 11, respectivamente os métodos putBuf() e putByte(). Foram também
implementados os métodos getBuf() e getByte(), que seguem os mesmos passos do
putBuf()
e putByte(), mas com objetivos contrários (quadro 12).
...
void putBuf() {
int8 i;
output_high(TRW_CE);
CSDELAY();
putByte(ADDR1_1); putByte(ADDR1_0);
for( i=0; i<BUF_MAX ; i++) {
putByte(buf[i]);
}
output_low(TRW_CE);
output_low(TRW_CLK1);
}
...
void putByte( byte b ) {
int8 i;
int8 p = 7;
for(i=0 ; i < 8 ; i++) {
output_low(TRW_CLK1);
if( bit_test(b,p--) ) {
output_high(TRW_DATA);
}else{
output_low(TRW_DATA);
}
CLKDELAY();
output_high(TRW_CLK1);
CLKDELAY();
}
}
...
Quadro 11 – Métodos para envio de dados
56
...
void getBuf() {
int8 i;
for (i=0; i<BUF_MAX; i++) {
buf[i] = getByte();
}
output_low(TRW_CLK1);
output_high(TRW_CE);
}
...
byte getByte() {
int8 i, b = 0;
int8 p = 7;
for (i=0; i<8; i++) {
output_low(TRW_CLK1);
CLKDELAY();
output_high(TRW_CLK1);
CLKDELAY();
if (input(TRW_DATA))
bit_set(b,p--);
else
bit_clear(b,p--);
}
return b;
}
...
Quadro 12 – Métodos para recebimento de dados
No código descrito no quadro 13, verifica-se a cada ciclo do laço while se existem
dados para pegar ou enviar no transmissor. O envio do dado recebido pelo transmissor é feito
em seguida byte-a-byte pelo comando putc().
57
#define BUFFER_SIZE 6
...
int8 q[BUFFER_SIZE]; //buffer temporário
int8 i=0;
int8 j=0;
...
while (1){
//loop infinito
if(input(TRW_DR1)){//verifica se exite dados no TRF para pegar
getBuf();
//pega dados e coloca no buffer (buf)
//envia bytes para porta serial
putc('+');
// caracter de inicialização
putc(buf[0]);
putc(buf[1]);
putc(buf[2]);
putc(buf[3]);
putc(buf[4]);
putc(buf[5]);
putc('-');
// caracter de finalização
}
if(i>=BUFFER_SIZE){//testa se já tem dados p/ transmitir via RF
for(j=0 ; j < BUFFER_SIZE; j++) {
buf[j] = q[j];
}
i = 0;
trwSetTx();
// muda para transmissor
delay_ms(1);
putBuf();
// manda pacote (buf)
delay_ms(1);
trwSetRx();
// muda para receptor
delay_ms(1);
}
...
}
...
//trata interrupção na chegada de bytes na porta serial
#int_rda
void serial_isr() {
int8 a;
a = getchar();
q[i] = a;
i++;
}
Quadro 13 – Laço principal do programa
No código apresentado no quadro 13 também foi apresentada a rotina que trata a
interrupção da porta serial. Todo byte recebido pela porta é colocado temporariamente no
array q[], que mais tarde é transmitido via rádio freqüência.
3.3.3.3
Controle trem
As funcionalidades do software embarcado no trem (especificado na figura 27) são:
58
acelerar e desacelerar, parar, inverter rotação do motor e detectar sensores dos trilhos. Sempre
que um trem passar sobre um sensor, será chamada uma rotina tratadora desta interrupção
(quadro 14). Com o comando enable_interrupts(int_rb) são habilitadas as interrupções
nos pinos RB7, RB6, RB5 e RB4. Caso haja uma mudança em algum destes pinos de alto
para baixo ou baixo para alto, a execução do software é desviada para a rotina
detect_rb_change().
sensorTrilho
Dentro do método é feito um teste (teste A) para certificar que o flag
não esteja ativado. No passo seguinte é testado (teste B) se o pino RB7 passou
do estado alto para baixo. Caso tenha, ativa-se o flag sensorTrilho para que em uma
próxima etapa do software seja enviada uma mensagem ao controle central, informando-o da
passagem do trem pelo sensor.
...
enable_interrupts(int_rb);
enable_interrupts(global);
...
#int_rb
void detect_rb_change() {
int1 current;
static int1 last=0;
if (!sensorTrilho){
current=input(pin_b7);
if ((last)&&(!current)){
sensorTrilho = 1;
}
last=current;
}
}
Teste A
Teste B
Quadro 14 – Rotina tratadora de interrupção do trem
No quadro 15 é apresentado o método responsável pela aceleração e desaceleração do
trem. A rotina tem como funcionalidade incrementar ou decrementar o valor da variável
velocidade.
A cada passagem pelo laço é informado o novo valor da variável a função
set_pwm1_duty(),
que faz a atualização do PWM. Para a função do PWM são aceitos
valores entre 0 e 255, sendo respectivamente a variação entre o trem estar parado ou em
velocidade máxima.
59
byte velocidade = 0;
...
//velocidade trem: acelera ou desacelera
void veloc(int8 &vel){
//desacelera gradualmente
while (velocidade > vel){
velocidade--;
set_pwm1_duty(velocidade);
delay_ms(15);
}
//acelera gradualmente
while (velocidade < vel){
velocidade++;
set_pwm1_duty(velocidade);
delay_ms(15);
}
}
...
veloc(buf[2]); //chamada do método veloc()
Quadro 15 – Método de aceleração e desaceleração com PWM
Os valores dos bytes [funcao], [valor1] e [valor2] que integram o array das
mensagem enviadas do controle central ao trem são descritos no quadro 16.
Função
Valor1
Valor2
a
0 até 255
0 até 255
p
-
-
i
-
-
R
0 até 255
Descrição
Comando para acelerar o trem, o valo1
representa a velocidade desejada e o
valor2
velocidade
necessária
para
o
arranque do motor.
Comando para parar o trem. Valor1 e valor2
não são necessários.
Comando para inverter o sentido da rotação
do motor.
Aviso de recebimento de uma resposta do
controle
central.
Valor1
contém
o
identificador
da
mensagem
que
foi
respondida.
Quadro 16 – Comandos aceitos pelo trem
3.3.3.4
Cruzamento
O quadro 17 apresenta a rotina que faz o tratamento da interrupção gerada pelos
sensores dos trilhos. Sempre que houver uma mudança nos estados dos pinos RB7 (sensor 1),
RB6 (sensor 2) e RB5 (sensor 3) a execução do programa será desviada para a rotina
detec_rb_change().
Neste método é verificado se a mudança de estado do pino foi para alto
ou baixo através da condição if ((last7)&&(!current7)). Caso tenha sido para baixo é
setado o flag sensorTrilho1.
60
#int_rb
void detect_rb_change() {
int1 current7;
static int1 last7=0;
int1 current6;
static int1 last6=0;
int1 current5;
static int1 last5=0;
//detecta a passagem no sensor1 / PIN RB7
if (sensorTrilho1 == 0){
current7=input(pin_b7);
if ((last7)&&(!current7)) {
sensorTrilho1 = 1;
}
last7=current7;
}
//detecta a passagem no sensor2 / PIN RB6
if (sensorTrilho2 == 0){
current6=input(pin_b6);
if ((last6)&&(!current6)) {
sensorTrilho2 = 1;
}
last6=current6;
}
//detecta a passagem no sensor3 / PIN RB5
if (sensorTrilho3 == 0){
current5=input(pin_b5);
if ((last5)&&(!current5)) {
sensorTrilho3 = 1;
}
last5=current5;
}
}
Quadro 17 – Rotina que detecta passagem por sensores
No quadro 18 é mostrado o código para o acionamento da bobina do cruzamento.
Foram implementados dois métodos, um para abrir o desvio e outro para fechar. Com a
instrução output_bit(pin_b3,1) é acionada a bobina. Após ser acionada é aguardado o
tempo de 800 milisegundos e então desligada, evitando assim o aquecimento da mesma. Para
abrir o desvio é necessário também acionar o relé para inverter a polarização da bobina.
void AbrirDesvio(){
output_bit(pin_a1,1);
output_bit(pin_b3,1);
delay_ms(800);
output_bit(pin_b3,0);
output_bit(pin_a1,0);
}
//relé da bobina
//saída da bobina
//desaciona bobina
//desliga o relé
void FecharDesvio(){
output_bit(pin_b3,1);
delay_ms(800);
output_bit(pin_b3,0);
}
Quadro 18 – Métodos para abrir e fechar desvio
61
Os valores dos bytes [funcao], [valor1] e [valor2] que integram o array das
mensagem enviadas do controle central ao cruzamento são descritos no quadro 19.
Função
Valor1
Valor2
m
a
-
m
f
-
R
0 até 255
Descrição
Comando para mudar a posição do desvio do
cruzamento.
O
valor1
identifica
que
deseja-se abrir o desvio. Valor2 não é
necessário.
Comando
para
fechar
o
desvio
do
cruzamento.
Aviso de recebimento de uma resposta do
controle
central.
Valor1
contém
o
identificador
da
mensagem
que
foi
respondida.
Quadro 19 – Comandos aceitos pelo cruzamento
3.4
OPERACIONALIDADE DA IMPLEMENTAÇÃO
A operacionalidade do hardware inicia-se com as ligações das fontes dos trilhos,
cruzamentos e do controlador. O segundo passo é colocar os trens nos trechos indicados pela
rota de cada um como trecho inicial.
Para iniciar o gerenciamento da malha pelo software do controle central é necessário
clicar no menu de Controle e em seguida escolher a opção de Iniciar (figura 37).
62
Figura 37 – Tela inicial do software
No menu de Cadastro estão disponíveis as opções de cadastro de trens e cruzamentos.
Na figura 38 é apresentada a tela de cadastro dos trens. Neste cadastro deve se informar: o ID
do trem, nome para identificação, velocidade de arranque, velocidade mínima e o caminho do
arquivo onde está descrita a rota em que o trem deve percorrer. A velocidade de arranque e
mínima é representada por um número percentual de 1 à 100%.
Figura 38 – Tela de cadastro de trens
A tela para cadastrar cruzamentos é apresentada na figura 39. Para cadastrar um
63
cruzamento é necessário informar o ID do cruzamento, um nome para identificação e os
identificadores de três sensores.
Para o preenchimento dos campos de sensores é levada em conta a montagem do
hardware na malha. No campo desvio aberto é informado qual o identificador do sensor que o
trem irá detectar ao passar pelo desvio na posição de aberto (quando o desvio está voltado
para parte curva). O mesmo ocorre para desvio fechado (quando o desvio está voltado para
parte reta). Os campos de sensor ID 1, 2 e 3 são para calibrar o sistema. Quando o software do
controle central receber do cruzamento que o sensor com ID 1 foi acionado, verificará qual o
identificador que foi informado no campo sensor ID 1 (S02). Em seguida será informado ao
trem que sua passagem foi pelo sensor S02.
Figura 39 – Tela de cadastro de cruzamentos
3.5
RESULTADOS E DISCUSSÃO
Desenvolver um protótipo de controle de uma malha ferroviária foi considerado
complexo, devido a quantidade de dispositivos envolvidos. A dificuldade está em adaptar um
ferrorama convencional para ser controlado por circuitos com microcontroladores.
A utilização do microcontrolador PIC16F628A para o controle realizado no hardware
mostrou-se eficiente para tarefas de controle de velocidade (PWM) e o uso de interrupções
para detecção de sensores. O componente TRF-2.4G proveu grande facilidade para transmitir
e receber mensagens.
Na montagem do hardware do trem teve-se problemas com o ruído gerado pelo motor
64
e com mau contato das rodas com os trilhos. Para resolver os problemas de mau contato foram
limpos os trilhos, as rodas e as palhetas (escovas que ficam encostadas nas rodas). Na placa
do trem foi adicionado na entrada do circuito um capacitor de 220uF para atenuar os picos
gerados pelo mau contato. Foram adicionados ao circuito capacitores cerâmicos para tentar
resolver o problema do ruído gerado pelo motor. Sem sucesso, foi revestida internamente a
carenagem do trem com papel alumínio e ligado ao terra. Mesmo com essas medidas, ainda
teve-se problemas de ruído. A última modificação foi a troca dos fios originais do trem por
cabos coaxais. Após aterrá-los notou-se uma melhora significativa na interferência dos ruídos.
Exceto pelos problemas citados acima, todas as outras funcionalidades esperadas do
protótipo foram alcançadas.
No quadro 20 é apresentado o comparativo das características do protótipo
desenvolvido com os trabalhos correlatos.
Características
Protótipo
desenvolvido
Trilhos
Trilhos
Trilhos
Pilhas
Redes de Petri
Processos concorrentes
Implementação em
hardware
Rádio freqüência
Alimentação dos
motores dos trens
Alimentação do
circuito dos trens
Sensores para detecção
da posição dos trens
Cruzamentos com
opção de desvio
automatizado
PWM para aceleração
dos trens
Schubert (2003)
Raulino
(1999)
Kluge (1999)
Trilhos
Java e C para
Linguagem de
Delphi
Ada
C++
microcontroladores
programação
PIC
Quadro 20 – Características do protótipo desenvolvido e trabalhos correlatos
65
4 CONCLUSÕES
Os objetivos propostos foram alcançados. A substituição do microcontrolador
PIC16F84A pelo PIC16F628A foi bem sucedida. O controle de velocidade (aceleração e
desaceleração) também foi bem sucedido, conforme desenvolvido. Com o novo componente
para comunicação, o TRF-2.4G, foi possível tornar mais eficiente e confiável a comunicação
entre controlador, trens e cruzamentos. A troca dos sensores (reed-switch) da lateral dos
trilhos (como acontecia no protótipo de Schubert (2003)) para dentro dos trilhos trouxe maior
precisão na detecção e também uma maior segurança, visto que sua fixação ficou mais
protegida, dificultando que seja retirado da posição estabelecida acidentalmente.
O componente TRF-2.4G teve fundamental importância no desenvolvimento deste
trabalho, pois apresenta um ambiente de alto nível para o envio e recebimento de dados via
rádio freqüência.
Para execução deste trabalho fez-se necessário o estudo do funcionamento do
componente
TRF-2.4G,
construção
de
circuitos
eletrônicos,
linguagem
C
para
microcontroladores e a utilização do microcontrolador PIC16F628A. Todos estes
componentes mostram-se adequados para o referido projeto. A linguagem Java também se
mostrou adequada para o desenvolvimento do software do controle central.
Há, no entanto limitações no trabalho desenvolvido. No software do controle central,
não é realizada consistência das rotas definidas para o trem, faltando um editor e um
compilador de rotas. O circuito desenvolvido para os cruzamentos é limitado a controlar
apenas um desvio e monitorar no máximo três sensores por cruzamento.
4.1
EXTENSÕES
Existem pontos que podem ser agregados ou melhorados no protótipo. Como sugestão
pode-se citar:
a) desenvolver um dispositivo para medir a velocidade do trem em tempo real,
possibilitando um controle mais suave e preciso no arranque inicial do motor;
b) controlar a passagem dos trens (entrada e saída) nos pontos da malha levando em
conta o tamanho dos mesmos (inclusive com número variado de vagões);
66
c) desenvolver um dispositivo capaz de identificar o real posicionamento do trem
sobre a malha ferroviária;
d) disponibilizar um controle manual dos dispositivos envolvidos na malha;
e) desenvolver um editor da malha ferroviária para a modelagem de trechos e
cruzamentos, possibilitando mostrar o mapa construído com a localização de cada
trem;
f) substituir porta serial do controlador por porta Universal Serial Bus (USB);
g) confeccionar as placas com a tecnologia Surface Mounted Devices (SMD), visando
diminuir o espaço ocupado nos trens;
h) utilização de sensores ópticos para detecção da passagem dos trens;
i)
utilização de ponte H (STMICROELECTRONICS, 2000) para inversão dos
motores dos trens.
67
REFERÊNCIAS BIBLIOGRÁFICAS
AMÉRICA LATINA LOGÍSTICA. Gestão voltada para segurança. Curitiba, [2005?].
Disponível em: <http://www.fae.edu/publicacoes/pdf/revista_fae_business/n13/all.pdf>.
Acesso em: 9 set. 2006.
BARR, Michael. Introduction to pulse width modulation. [S.l.], 2001. Disponível em:
<http://www.embedded.com/story/OEG20010821S0096>. Acesso em: 9 set. 2006.
DOYLE, Paul; ZACKER, Craig. Redes de computadores: configuração, manutenção e
expansão. São Paulo: Makron, 2000.
FRATESCHI. [Brasil], [2007?]. Disponível em: <http://www.frateschi.com.br>. Acesso em:
21 mar. 2007.
GHIRARDELLO, Ariovaldo. Apostila sobre modulação PWM. [São Paulo], [2006?].
Disponível em:
<http://www.equipetecnica.com.br/cursos/apostila_curso_pwm/apostila_pwm.pdf>. Acesso
em: 05 abr. 2007.
JANCZURA, Chris W. Modelling and analysis of railway network control logic using
coloured Petri nets, 1998. 246 f. Thesis (Doctor of Philosophy in Mathematics) - School of
Mathematics and Institute for Telecommunications Research, University of South Australia,
Australia. Disponível em:
<http://citeseer.ist.psu.edu/cache/papers/cs/19121/http:zSzzSzwww.itr.unisa.edu.auzSztech_r
eszSzpublicationszSzcwj.pdf/janczura98modelling.pdf>. Acesso em: 27 ago. 2006.
JAMESON, John. Proteus. [Inglaterra], 2006. Disponível em: <http://www.labcenter.co.uk>.
Acesso em: 9 set. 2006.
JARVI, Keane. RXTX: the prescription for transmission. [S.l.], 1998. Disponível em:
<http://www.rxtx.org>. Acesso em: 25 fev. 2007.
KALT, Marcel. NSD-Editor: Nassi-Shneiderman diagram editor. [S.l.], 1997. Disponível em:
< http://diuf.unifr.ch/softeng/student-projects/completed/kalt/ftp-nsd.html>. Acesso em: 28
abr. 2007.
KLUGE, Werner. The model railway. [Alemanha], [1999?]. Disponível em:
<http://www.informatik.uni-kiel.de/~railway/index.html>. Acesso em: 27 ago. 2006.
LAIPAC TECH. [Canadá], [1998?]. Disponível em: <http://www.laipac.com>. Acesso em:
15 set. 2006.
68
_____. TRF-2.4G transceiver data sheet. [Canadá], [2005?]. Disponível em:
<http://www.tato.ind.br/files/RF-24G_datasheet.pdf>. Acesso em: 15 set. 2006.
LOMBARDO, John. Embedded Linux. Indiana: New Riders, 2002.
MICROCHIP. Microchip PIC16F628A. [S.l], 2005. Disponível em:
<http://ww1.microchip.com/downloads/en/DeviceDoc/40044D.pdf>. Acesso em: 27 ago.
2006.
PÉRICAS, Francisco A. Redes de computadores: conceitos e arquitetura Internet.
Blumenau: EdiFurb, 2003.
RAULINO, Rangel G. Uma aplicação para o controle do tráfego ferroviário usando
processos concorrentes. 1999. 82 f. Trabalho de Conclusão de Curso (Bacharelado em
Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de
Blumenau, Blumenau.
RONCARATI, Vinícius S. Ferrovias e ferreomodelismo. [S.l.], [1998?]. Disponível em:
<http://www.fortunecity.com/marina/manatee/71/trens.html>. Acesso em: 27 ago. 2006.
SCHUBERT, Lucas A. Aplicativo para controle de ferrovia utilizando processamento em
tempo real e redes de Petri. 2003. 88 f. Trabalho de Conclusão de Curso (Bacharelado em
Ciências da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de
Blumenau, Blumenau.
SPARX. Enterprise Architect. [Austrália], 2007. Disponível em:
<http://www.sparxsystems.com.au>. Acesso em: 03 feb. 2007.
STMICROELECTRONICS. [Itália?], [2000]. Disponível em:
<http://www.st.com/stonline/books/pdf/docs/1773.pdf>. Acesso em: 16 jul. 2007.
TAURION, Cezar. Software embarcado: oportunidades e potencial de mercado. Rio de
Janeiro: Brasport, 2005.
TANENBAUM, Andrew S. Redes de computadores. Rio de Janeiro: Campus, 2003.
VENCOVSKY, Vitor P. Sistema ferroviário e o uso do território brasileiro: uma análise
do movimento dos produtos agrícolas. 2006. 167 f. Dissertação (Mestrado em Geografia) –
Curso de Pós-graduação em Geografia, Universidade Estadual de Campinas, Campinas.
Disponível em: < http://libdigi.unicamp.br/document/?code=vtls000376994>. Acesso em: 27
ago. 2006.
ZANCO, Wagner S. Microcontroladores PIC16F628A/648A: uma abordagem prática e
objetiva. São Paulo: Érica, 2005.