Post on 25-Mar-2020
transcript
Licenciatura em Engenharia Electrotécnica e de Computadores
Relatório do Projecto Final de Curso
Trabalho realizado:
António Vieira
Paulo Santos
Orientador:
Prof. Dr. Artur Cardoso
FEUP, Porto Dezembro de 2001
Índice
1. Introdução.................................................................................................................. 4
2. Motivação .................................................................................................................. 4
3. Protocolo CAN ........................................................................................................... 5
3.1. Como Funciona o CAN?..................................................................................... 7
3.1.1. Tramas ....................................................................................................... 8
3.1.2. Detecção e correcção de erros................................................................... 8
3.1.3. Implementações do CAN............................................................................ 9
4. Descrição do projecto .............................................................................................. 11
4.1. Objectivos ........................................................................................................ 11
4.2. Material ............................................................................................................ 11
4.3. Descrição do Siemens C167CR-LM e do Intel 82527....................................... 13
4.3.1. Siemens C167CR-LM............................................................................... 13
4.3.2. Intel 82527................................................................................................ 14
4.3.2.1. Cálculos do tempo de bit “Bit timing”................................................. 17
5. Arquitectura do sistema............................................................................................ 20
5.1. Escolha das linguagens de programação......................................................... 20
5.2. Escolha do servidor.......................................................................................... 21
5.3. Escolha da simulação....................................................................................... 21
5.3.1. Conceito de domótica ............................................................................... 21
6. Estrutura geral de funcionamento ............................................................................ 22
7. Estruturação do software ......................................................................................... 24
7.1. Descrição das funções ..................................................................................... 25
7.1.1. Funções implementadas em “ime_acc.c”................................................. 25
7.1.2. Funções implementadas em “CANfunc.c”................................................. 26
7.2. Descrição dos “headers” .................................................................................. 27
7.3. Descrição das aplicações “executáveis”........................................................... 27
7.3.1. Inicializa - CANinic.c ................................................................................. 28
7.3.2. Envia - CANenv.c ..................................................................................... 29
7.3.3. Recebe - CANrcb.c................................................................................... 30
7.3.4. VeRemota - CANvermt.c .......................................................................... 30
7.3.5. Rmt - CANrmt.c ........................................................................................ 31
8. Estrutura da página WEB......................................................................................... 32
8.1. Mapa do site..................................................................................................... 33
8.2. Interfaces (Forms) ............................................................................................ 34
8.2.1. Configuração dos registos ........................................................................ 34
8.2.2. Envio de mensagens ................................................................................ 35
8.2.3. Recepção de mensagens ......................................................................... 36
8.2.4. Envio de tramas remotas.......................................................................... 37
8.3. Programação em PHP...................................................................................... 38
8.4. Programação em HTML ................................................................................... 40
9. Simulação com os nós X e Y ................................................................................... 41
9.1. Objectivos ........................................................................................................ 41
9.2. Atribuição de identificadores............................................................................. 41
9.3. Interface de Simulação..................................................................................... 42
9.4. Adaptação das EvaBoards à simulação ........................................................... 43
10. Futuros desenvolvimentos ....................................................................................... 44
10.1. Base de dados dos movimentos importantes na rede................................... 44
10.2. Software das EvaBoards .............................................................................. 44
10.3. Desenvolver Periféricos para ligação às EvaBoards..................................... 44
10.4. Desenvolver uma aplicação cliente/servidor................................................. 44
11. Conclusões .............................................................................................................. 46
Bibliografia e referências: ................................................................................................ 48
Tabelas
Tabela 1: Compatibilidade entre tipos de controladores CAN ............................................ 6
Tabela 2: Características do BasicCAN e do FullCAN ....................................................... 9
Tabela 3: Ficheiros envolvidos nas aplicações ................................................................ 25
Tabela 4: Descrição das funções implementadas em “ime_acc.c”................................... 25
Tabela 5: Descrição das funções implementadas em “CANfunc.c”.................................. 26
Tabela 6: Descrição das aplicações................................................................................. 27
Tabela 7: Estrutura do Message Configuration Register .................................................. 29
Tabela 8: Descrição dos ficheiros “php” para o módulo Evolução.................................... 38
Tabela 9: Descrição dos ficheiros “php” para o módulo EvaBoards ................................. 38
Tabela 10: Descrição dos ficheiros “php” para o módulo Configuração............................ 39
Tabela 11: Descrição dos ficheiros “php” para o módulo Rede CAN................................ 39
Tabela 12: Descrição dos ficheiros “php” para o módulo Simulação................................ 39
Tabela 13: Descrição dos identificadores atribuídos ........................................................ 41
Tabela 14: Descrição dos Bits usados ............................................................................. 42
Figuras
Figura 1 – Diagrama de blocos do 82527 ........................................................................ 15
Figura 2 – Mapa de endereços do 82527......................................................................... 16
Figura 3 – Estrutura dos Objectos Mensagem ................................................................. 16
Figura 4 – Segmentos de tempo de um bit CAN definidos pela norma ISO11898 ........... 17
Figura 5 – Programa para cálculo do “Bit Timing”............................................................ 18
Figura 6 – Página gerada pelo “Site” de “Bit Timing” ....................................................... 19
Figura 7 – Arquitectura do sistema .................................................................................. 20
Figura 8 – Arquitectura do servidor.................................................................................. 22
Figura 9 – Estruturação de compilação dos programas ................................................... 24
Figura 10 – Funcionamento da aplicação “inicializa”........................................................ 28
Figura 11 – Funcionamento da aplicação “envia”............................................................. 29
Figura 12 – Funcionamento da aplicação “recebe” .......................................................... 30
Figura 13 – Menu de interligação dos módulos................................................................ 32
Figura 14 – Mapa da página WEB alojada no servidor .................................................... 33
Figura 15 – Interface para configuração dos registos....................................................... 34
Figura 16 – Interface para envio de mensagens .............................................................. 35
Figura 17 – Interface para recepção de mensagens ........................................................ 36
Figura 18 – Interface para envio de tramas remotas........................................................ 37
Figura 19 – Interface de Simulação ................................................................................. 43
Gateway CAN WWW – Projecto Final de Curso 2000/2001
4
1. Introdução
Os objectivos principais deste projecto são em primeiro a formalização de um sistema
integrado de serviços com o intuito de melhorar e desenvolver as Tecnologias de
Automação Computacional, tais como a integração de aplicações em sistemas de
controlo e monitorização de redes CAN (Controller Area Network) e a sua interligação
com uma rede TCP/IP. Foi feito um estudo das tecnologias envolvidas, no qual nos
baseamos para implementar o nosso sistema. Em segundo, a arquitectura e
implementação do sistema é feita através de um PC, que será o servidor de acesso à
rede CAN, e as Placas Microcontroladoras (nós CAN) para controlo de sensores e
actuadores diversos.
2. Motivação
A utilização do sistema CAN torna-se uma alternativa económica de rede de dados para
muitas aplicações industriais por providenciar um acondicionamento entre sensores,
actuadores e toda a distribuição e controlo em tempo real de dados através do bus. Aliado
a estes factos, é importante também existir um interface entre a rede CAN e outras redes,
para assim proporcionar o seu controlo e monitorização remota. É com este intuito que
surgiu a ideia de criar uma “Gateway CAN”, permitindo assim a gestores e
administradores de redes CAN o controlo e monitorização de processos numa dada rede.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
5
3. Protocolo CAN
O CAN - Controller Area Network é um protocolo de comunicação digital, série e multi-
mestre que suporta eficazmente sistemas de controlo distribuído. O CAN é normalmente
usado em sistemas embebidos, sendo a rede estabelecida entre microcontroladores.
O CAN foi desenvolvido pela Robert Bosch GmbH, na Alemanha, em 1986, com o intuito
de ligar três “ECU” (Electronics Control Units) nos veículos Mercedes-Benz. O primeiro
“Chip” CAN foi fabricado pela Intel em 1987. Além do CAN, surgiram outros protocolos
para o uso na indústria automóvel como o ABUS da Volkswagen, o VAN da Peugeot e da
Renault e o J1850 da Chrysler, General Motors e Ford.
Actualmente, o CAN tem vindo a assumir uma posição de líder do mercado, o que leva
muitos construtores a abandonar os seus protocolos proprietários, adoptando o CAN
principalmente por razões económicas e pelo seu fácil desenvolvimento. Ao ser idealizado
para comunicação entre sensores e actuadores, outras áreas de aplicação se têm aberto
para este protocolo.
Sendo a sua utilização mais notada ainda na indústria automóvel, é também usado em
automação industrial, comboios e maquinaria pesada, aeronáutica, equipamento médico,
automação de edifícios, electrodomésticos entre muitas outras aplicações. A produção de
elevados números de dispositivos a que a indústria automóvel obriga, tornou-o disponível
a baixo custo, o que em conjunto com o elevado grau de capacidades de tempo real e
controlo distribuído, levou ao seu uso alargado.
O protocolo CAN implementa apenas as duas camadas inferiores do modelo OSI (Open
Systems Interconnect) da ISO (International Standards Organization): a camada física e a
camada de ligação de dados. O protocolo CAN é estandardizado pela ISO e pela SAE
(Society of Automotive Engineers). A ISO definiu dois Standards, sendo a diferença na
camada física, onde na ISO 11898 suporta aplicações com velocidades até
1Mbit/segundo e a ISO 11519 tem um limite superior de 125kbits/segundo.
À especificação original da Bosch, seguiu-se a Versão 2.0 que é dividida em duas partes:
- “Standard CAN“ (Versão 2.0A) usa identificadores de 11 bits.
- “Extended CAN“ (Versão 2.0B) usa identificadores de 29 bits.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
6
As duas partes definem diferentes formatos de mensagem, sendo a principal diferença o
comprimento do identificador.
O facto de existirem duas especificações (Parte A e Parte B) levanta alguns problemas de
compatibilidade. Existem três tipos de controladores CAN: Parte A, Parte B passivo e
Parte B activo, sendo as suas compatibilidades descritas na tabela 1.
Formato da mensagem Parte A Parte B Passivo Parte B Activo
Identificador de 11 bit compatível compatível compatível
Identificador de 29 bit ERRO!! tolerado na rede, mas ignorado compatível
Tabela 1: Compatibilidade entre tipos de controladores CAN
As características do CAN são:
- Estabelece prioridade nas mensagens;
- Recepção múltipla com sincronização no tempo;
- Consistência de dados através da rede;
- Multi-mestre;
- Detecção e sinalização de erros;
- Retransmissão automática de mensagens corrompidas assim que a rede
estiver livre;
- Distinção entre erros temporários e falhas permanentes de nós e desligar
automático de nós.
Devido ao aumento de popularidade da arquitectura CAN, existe um número elevado de
vendedores e fabricantes que produzem controladores CAN, tais como a Intel, Motorola,
NEC, National Semiconductor, Philips e Siemens. Como resultado, os preços dos
mesmos não param de diminuir e a arquitectura CAN está cada vez mais a tornar-se uma
opção viável em muitas áreas de controlo e automatização de sistemas. O potencial desta
arquitectura, advém dos requisitos demonstrados no que diz respeito à velocidade de
transmissão e controlo em tempo real de sensores e actuadores.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
7
3.1. Como Funciona o CAN?
O CAN utiliza a codificação NRZ (Non Return to Zero) com bit-stuffing, para a
comunicação de dados num barramento diferencial de dois fios (geralmente par
entrelaçado). O Padrão ISO 11898 recomenda até que os transceivers sejam
desenvolvidos de forma a suportar a comunicação, mesmo que um dos fios seja cortado
ou curto-cirtuitado à fonte de alimentação ou à massa. A utilização de identificadores em
vez de endereços facilita a configuração do sistema, podendo suportar ainda as
capacidades de receptores múltiplos e multi-mestre.
O método CSMA/CD+AMP (Carrier Sens, Multiple Access with Collision Detection and
Arbitration on Message Priority) é o utilizado no CAN. Antes de enviar uma mensagem, o
nó verifica se o barramento se encontra ocupado. Aquando da transmissão verifica
também se ocorreu alguma colisão. Neste aspecto, o CAN é similar a Ethernet. Contudo,
quando esta detecta uma colisão, ambos os nós que se encontravam a enviar param.
Depois de um tempo de espera aleatório tentam iniciar novamente a transmissão. Isto
torna a Ethernet muito sensível a elevadas cargas na rede. O CAN resolve este problema
com um princípio inteligente de arbitragem.
Uma mensagem transmitida por qualquer nó CAN não contém endereço, nem do nó
emissor nem do nó receptor.
Cada mensagem tem um identificador que é único na rede. Todos os outros nós recebem
a mensagem e executam testes ao identificador, para determinar se o seu conteúdo é de
interesse para esse nó. Se a mensagem for importante para o nó é processada; se não é
ignorada.
O identificador único também determina a prioridade da mensagem. Quanto menor for o
valor numérico do identificador, maior será a sua prioridade. Isto permite a arbitragem
entre várias mensagens que tentam aceder à rede ao mesmo tempo.
À mensagem prioritária é garantido o acesso como se ela fosse a única a tentar aceder à
rede. As mensagens com prioridade menor serão automaticamente retransmitidas na
primeira vez que o barramento estiver livre e não existirem mensagens com maior
prioridade a serem transmitidas.
Cada mensagem CAN possui um identificador de 11 bits (Parte A) ou 29 bits (Parte B)
que é parte do Arbitration Field e que se encontra na parte inicial da mensagem.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
8
Como CAN utiliza a codificação NRZ os bits são sempre codificados como “1” (5 V) ou “0”
(0 V). No CAN os bits “0” são sempre dominantes, o que quer dizer que em caso de
colisão entre um “0” e um ”1” o resultado da rede será um “0” (Wired-And). E como os
nós, quando a transmitir, escutam também a rede, se este “ler” um “0” quando tentou
“escrever” um “1” sabe que perdeu a prioridade para outro nó. Em consequência, pára de
transmitir, permitindo que o outro nó (prioritário em relação a ele) continue sem
interrupções.
Dois nós numa mesma rede não podem enviar mensagens de dados com o mesmo
identificador. Se tal acontecer, o critério de arbitragem de acesso à rede falha. Um dos
nós detectará a sua mensagem distorcida, e enviará uma trama de erro ; como dois nós
tentam transmitir com o mesmo identificador, isto levará a que um dos nós fique Bus-Off.
Convém referir, que nesta regra além do identificador é testado o bit RTR (Remote
Transmition Request), que evita qualquer problema quando uma mensagem colide com
um pedido remoto com o mesmo identificador. A mensagem de dados, que tem o bit RTR
a zero, ganha o acesso à rede face ao pedido remoto que tem o bit RTR a um.
3.1.1. Tramas
O protocolo CAN suporta quatro tipos de tramas de comunicação:
- Trama de Dados (Data Frame)
- Trama Remota (Remote Frame)
- Trama de Erro (Error Frame)
- Trama de Sobrecarga (Overload Frame)
Toda a comunicação entre nós é efectuada com recurso a estas tramas. O CAN tem
mecanismos que detectam qualquer erro de forma, em relação a estes padrões, como
veremos a seguir.
3.1.2. Detecção e correcção de erros
O CAN possui mecanismos para detecção de cinco tipos de erros:
- Bit error
Durante a transmissão o bit monitorado é diferente do bit enviado. Não se
aplica durante a transmissão do Arbitration Field e ACK Slot;
Gateway CAN WWW – Projecto Final de Curso 2000/2001
9
- Stuff error
Detecção de um sexto bit igual consecutivo;
- Cyclic Redundancy error (CRC)
O cálculo do CRC pelo receptor não é igual ao CRC recebido;
- Form error
Detecção de um erro na estrutura da trama;
- Acknowledgement Error
O receptor não recebeu confirmação de recepção por parte de nenhum nó.
3.1.3. Implementações do CAN
A especificação CAN não aborda a forma como os controladores e restantes dispositivos
devem ser implementados ou como devem responder às diferentes solicitações, quer da
rede quer das aplicações. Existem por isso duas estratégias principais de implementação:
o BasicCAN e o FullCAN. As principais diferenças entre elas estão na forma como as
mensagens são filtradas, na forma como as mensagens são guardadas nos buffers, na
resposta às tramas remotas e na carga imposta ao CPU. Uma breve descrição destas
estratégias é dada na tabela 2. Uma outra diferença importante é o custo destas
implementações: o BasicCAN é usado em controladores Stand-Alone e em pequenos
microcontroladores com CAN integrado de baixo custo, enquanto que o FullCAN é usado
em controladores e microcontroladores de elevadas performances de mais alto custo.
BasicCAN FullCAN
Transmissão
A aplicação tem de atribuir o Id
e restantes parâmetros para
cada transmissão
Mailboxes inicializadas uma vez;
só os Data bytes são escritos
antes da transmissão
Recepção
Normalmente dois Buffers em
FIFO. Filtro global (filtragem
final realizada pela aplicação)
Só as mensagem com Id
definidas numa Receive Mailbox
serão recebidas. Filtro exacto (só
são aceites as mensagem com o
Id exacto)
Resposta às
Tramas remotas Pela aplicação Pelo controlador
Filosofia de
sobreposição
Mantêm a mensagem mais
antiga.
Mantêm a mensagem mais
recente.
Tabela 2: Características do BasicCAN e do FullCAN
Gateway CAN WWW – Projecto Final de Curso 2000/2001
10
Alguns pormenores do funcionamento destas implementações merecem a nossa atenção.
No BasicCAN as mensagens podem-se perder, se o CPU não for suficientemente rápido
a ler os buffers. Um outro pormenor é a escolha dos identificadores, que devem
possibilitar uma janela de filtragem o mais pequena possível, de forma a garantir um nível
de carga ao CPU aceitável. Em BasicCAN este tem de realizar a filtragem final e
responder às tramas remotas. Quanto ao FullCAN levantam-se dois problemas. Como a
resposta às tramas remotas é automática, pode ocorrer que as informações requerida e
enviada não sejam as mais actuais, pois estas são enviadas sem recurso ao CPU. O
outro problema é o número limitado de objectos mensagem, que podem não ser
suficientes para a aplicação. Algumas implementações reconfiguram os objectos
mensagem conforme as necessidades, enquanto alguns fabricantes disponibilizam
controladores com as duas estratégias implementadas parcialmente: têm algumas
mailboxes mas também tem buffers de forma a resolver este problema.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
11
4. Descrição do projecto
4.1. Objectivos
Este projecto tinha como objectivos definidos a criação de uma gateway entre uma rede
TCP/IP e uma rede CAN. Este gateway deveria permitir a monitorização e controlo de
uma aplicação ou processo baseado na rede CAN, a partir de qualquer PC ligado à rede
TCP/IP, no limite a partir de qualquer PC ligado à Internet.
4.2. Material
Para a execução deste projecto foi disponibilizado um StarterKit CAN da empresa alemã
especializada em CAN, I+ME Actia.
Este Kit é constituído essencialmente por duas placas EvaBoard C167C e por uma placa
PcNetBoard III, respectivos manuais e algumas disquetes de software de apoio à
utilização das placas.
As Placas EvaBoard C167C são dois nós CAN baseados no Microcontrolador Siemens
C167CR-LM, com 256 Kbytes de memória RAM e 512 Kbytes de memória ROM.
Possuem um Transceiver CAN em conformidade com a norma ISO 11898, um
Transceiver RS-232, uma saída/entrada analógica bem como um conjunto de oito leds e
oito interruptores que permitem interagir com a placa de forma simples. Possuem ainda,
um vasto conjunto de jumpers que permitem configurar de diferentes formas o
funcionamento das placas. Também estão equipadas com um ligador DIN41612 de 160
pinos que disponibiliza todos os sinais do C167CR-LM, e para o qual existem duas placas
de ligação, uma com um reóstato (sensor) e outra com um amperímetro (actuador), o que
possibilita a execução de testes iniciais
A placa PcNetBoard III utiliza o Micro Intel 82527 (Stand Alone CAN Controller) e permite
a interligação entre o CAN e um PC por intermédio de um slot ISA. O facto de permitir o
acesso directo do CPU ao controlador, mapeado como memória, facilita a programação
das aplicações. Esta placa possui dois jumpers, que permitem definir o IRQ e o endereço
base da placa.
Os respectivos manuais de utilização são disponibilizados em anexo.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
12
Quanto ao software disponível, todo ele desenvolvido para MS-DOS com recurso à
linguagem C, era constituído por diversos programas:
- PcControl - Permite o envio e recepção de mensagens; definição de alguns bits
de controlo e a visualização do conteúdo da RAM do 82527.
- 167Ctrl - Permite o envio e recepção de mensagens; definição de alguns bits de
controlo e a visualização do conteúdo da RAM do C167.
- PcNet - Permite a monitorização da rede e o envio e recepção de mensagens.
Foi também disponibilizada a livraria de software xxx-SoftDriv VM0, também ela
desenvolvida em C. Esta livraria é baseada na investigação desenvolvida pela I+ME no
decorrer do projecto europeu PROMETHEUS, e implementa uma série de funções e
serviços na rede CAN.
Sendo uma ferramenta poderosa, infelizmente revelou-se inútil, devido a diversos
factores. O código é bastante complexo, praticamente sem comentários e no total
implicava a inclusão de três ficheiros .C e de sete ficheiros .H (Header file) em qualquer
código gerado, usando esta ferramenta. Os diferentes ficheiros interligam-se de forma
complexa e não muito transparente. Outro factor negativo é o facto de que as diversas
variáveis de configuração da livraria se espalharem por diferentes ficheiros e não se
encontrarem assinaladas no código, ou mesmo referidas no manual que a acompanha.
Isto tornou a adaptação da livraria ao hardware e software no nosso PC impossível, após
longas horas de insistência com diferentes aproximações.
A Placa PcNetBoard III foi montada num PC baseado no Intel Pentium-S 166Mhz, com o
sistema operativo Windows 95. Devido a um vírus, não detectado pelo Antivírus instalado,
fomos forçados durante o recorrer do projecto a reinstalar o SO, tento na altura optado
pelo Windows 98.
Em relação ao kit disponibilizado é de salientar que este se encontra incompleto, faltando
algumas disquetes de software ,o Cabo de ligação RS232 e o conversor necessário para
a ligação do barramento CAN de ligação às EvaBoards à PcNetBoard. A falta deste último
item revelou-se problemática, pois este não se encontra referenciado nos manuais que
acompanham o kit, mas é necessário para a correcta ligação das placas. Para colmatar
esta falta, construímos um substituto do conversor que assegura a correcta conversão
entre standard CAN I+ME Actia e o standard CAN CiA.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
13
4.3. Descrição do Siemens C167CR-LM e do Intel 82527
Por estarmos a desenvolver uma aplicação que irá trabalhar com estes dois Chips,
convém referir alguns pormenores básicos das suas arquitecturas.
4.3.1. Siemens C167CR-LM
O Siemens C167CR-LM tem um módulo de CAN que suporta a versão 2.0 da
especificação CAN e foi desenhado de forma a ser usado em aplicações industriais e da
indústria automóvel. As suas características principais são:
- CPU 16-bit;
- Velocidade de relógio do CPU até 33MHz;
- 4kByte de memória SRAM;
- Módulo de CAN;
- Controlador de Periféricos (PEC);
- Duas unidades de captura/comparação de 16 canais;
- Unidade de PWM de 4 canais;
- Conversor A/D de 16 canais 10Bit;
- Duas unidades multifuncionais de uso geral com 5 timers de 16 bits;
- Watchdog Timer programável;
- Dois canais série (Síncrono/assíncrono e síncrono de alta velocidade);
- Bootstrap Loader incorporado;
- Até 111 linhas de E/S para uso geral;
- Alimentação a 5 Volt;
- Invólucro MQFP de 144 Pinos;
- Variação de temperatura compatível com viaturas: -40°C to +125°C.
O módulo CAN integrado trata de modo completamente autónomo da transmissão e
recepção das tramas CAN, de acordo com a especificação versão 2.0 (parte B activo). O
módulo permite o FullCAN até 15 objectos mensagem; o objecto mensagem 15 permite o
funcionamento em BasicCAN. Todos os objectos mensagem podem ser actualizados de
forma independente em relação aos restantes e podem receber mensagens até 8 bytes.
O bit timing é derivado do XCLK e é programável até um data rate de 1 Mbit/s.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
14
4.3.2. Intel 82527
O 82527 é o primeiro controlador CAN da Intel a implementar a versão 2.0 da
especificação CAN. As suas características principais são:
- Suporte da Versão 2.0 da especificação
- Tramas de dados e remotas standard
- Tramas de dados e remotas estendidas
- Máscara global programável
- Identificador standard
- Identificador estendido
- 15 objectos mensagem com dados até 8 bytes
- 14 buffers receptor/emissor
- 1 buffers receptor com mascara programável
- Interface com CPU flexível
- Multiplexada a 8 bits
- Multiplexada a 16 bits
- Síncrona não - multiplexada a 8 bits
- Assíncrona não - multiplexada a 8 bits
- Série
- Bit Rate programável
- Saída de relógio programável
- Estrutura de interrupção flexível
- Entrada comparadora configurável
- Duas portas E/S de 8 bits bidireccional
- Invólucro QFP de 44 Pinos/Invólucro PLCC de 44 Pinos
- Pinout compatível com o 82526.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
15
O 82527 tem um diagrama funcional dividido em seis blocos conforme a figura 1:
Figura 1 – Diagrama de blocos do 82527
O bloco CPU interface logics controla a ligação do 82527 ao CPU, no nosso caso do PC,
usando um barramento de endereços/dados. O bloco CAN controller implementa o
protocolo CAN para a recepção e envio de mensagem e o interface da rede CAN com o
82527. A RAM é a camada de interface entre o CPU e a rede CAN. As duas portas
permitem E/S de baixa velocidade a 8 bits. O bloco Clockout permite ao 82527 controlar
outros dispositivos.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
16
Figura 2 – Mapa de endereços do 82527
Na RAM do 82527 estão implementados 15 objectos mensagem com capacidade de 8
bytes para dados (figura2). Cada objecto mensagem tem um identificador que é único
para a rede e pode ser configurado para receber ou enviar mensagens com esse
endereço, à excepção do objecto mensagem 15. Este tem um filtro próprio desenhado
para permitir receber diferentes grupos de identificadores, possibilitando a recepção de
mensagens pouco usuais para determinada rede.
Figura 3 – Estrutura dos Objectos Mensagem
Gateway CAN WWW – Projecto Final de Curso 2000/2001
17
Cada objecto mensagem contém bits de controlo e de estado, facilmente configuráveis
pelo CPU (Figura 3). Um objecto mensagem configurado para receber, enviará uma trama
remota se lhe for requerido o envio de uma mensagem. Os objectos mensagem
configurados para o envio, responderam automaticamente a uma trama remota com o
“seu” identificador, sem recorrer ao CPU (FullCAN).Todos os objectos mensagem têm bits
de controlo e estado separados de forma a possibilitar ao CPU uma fácil detecção do tipo
de mensagem enviada.
O 82527 permite filtrar os identificadores à medida da aplicação, visto ter dois filtros
globais, um para mensagens com identificador standard e outro para estendido.
Primeiro a mensagem, passa por este filtro global e é posteriormente comparada com os
identificadores presentes nos objectos mensagem de 1 a 14. Se não for igual a nenhum,
passa então, pelo filtro do objecto mensagem 15. Isto permite que sejam recebidas no
objecto mensagem 15 mensagens pouco usuais.
4.3.2.1. Cálculos do tempo de bit “Bit timing”
O tempo nominal de bit, é definido como sendo a duração de um bit, correspondendo ao
inverso da taxa nominal de transmissão (número de bits por segundo transmitidos) de um
emissor ideal na ausência de ressincronização. Os segmentos que constituem o tempo de
bit são ilustrados na figura seguinte.
Figura 4 – Segmentos de tempo de um bit CAN definidos pela norma ISO11898
As funções de gestão do barramento executadas durante o tempo de bit, tais como o
ajuste da sincronização de um nó, atraso de compensação da transmissão da rede e a
posição dos pontos de amostragem, são definidas pela lógica programável do tempo de
bit do controlador. Os segmentos que constituem o tempo bit são:
- Segmento de Sincronização, SYNC_SEG. Este segmento é usado para sincronizar os
vários nós do barramento, sendo esperada uma transição durante o mesmo;
Gateway CAN WWW – Projecto Final de Curso 2000/2001
18
- Segmento do Tempo de Propagação, PROP_SEG. Este segmento é utilizado para
compensar os tempos de atraso físico na rede. Estes atrasos consistem nos tempos de
propagação do sinal na linha do barramento e nos tempos de atraso interno aos nós;
- Segmentos 1 e 2 dos buffers de fase, PHASE_SEG1 e PHASE_SEG2. Estes segmentos
são utilizados para compensar erros de fase nas transições. Estes segmentos podem ser
alongados ou encurtados por ressincronização;
- Ponto de amostragem, “Sample Point” é o instante no qual é lido e interpretado o nível
do barramento como sendo o valor do respectivo bit. Ocorre no final do segmento
Seg1_Fase. O tempo de processamento de informação é o segmento de tempo que tem
início no ponto de amostragem e é reservado para cálculos do nível de bit subsequente.
Para o cálculo do bit timing foram usados os exemplos ilustrados na datasheet do
controlador 82527, e também, um site na Internet e um programa de cálculo da empresa
KVASER AB [http://www.kvaser.se/can].
O programa Bit Timing Registers pode ser usado para todos os controladores CAN com
os registos compatíveis com o 82C200, por exemplo, 82527, sja1000, e MC68HC705.
Os parâmetros do programa são os apresentados na figura seguinte:
Figura 5 – Programa para cálculo do “Bit Timing”
Alterando os valores destes parâmetros, podemos saber quais os valores dos registos a
configurar para uma dada frequência do barramento CAN.
Na especificação do programa referia que a frequência de relógio teria que ser o dobro,
daí os 20Mhz.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
19
Outro método usado foi uma página WEB que permitia introduzir os valores de frequência
de relógio e o ponto de amostragem Sample Point, e de seguida apresentava os valores
dos registos para uma dada frequência do barramento CAN, a figura seguinte ilustra este
procedimento.
Bit Timing Tables for CANopen Bit Rates (http://www.port.de/engl/canprod/content/sv_req_form.html) CAN Controller type is Philips with a Clock Rate of 10 MHz, desired Sample Point at 62.5 %. Emphasized are rows with 16 time quanta.
Bit Rate
Pre- scaler
Number of time quanta
Seg 1 (Prop_Seg+Phase_Seg1)
Seg 2 Sample Point at %
Register BTR0
Register BTR1
1000 0 10 5 4 60.0 0x00 0x34
500 0 20 12 7 65.0 0x00 0x6b
500 1 10 5 4 60.0 0x01 0x34
250 1 20 12 7 65.0 0x01 0x6b
250 3 10 5 4 60.0 0x03 0x34
250 4 8 4 3 62.5 0x04 0x23
125 3 20 12 7 65.0 0x03 0x6b
125 4 16 9 6 62.5 0x04 0x58
125 7 10 5 4 60.0 0x07 0x34
125 9 8 4 3 62.5 0x09 0x23
100 3 25 15 9 64.0 0x03 0x8e
100 4 20 12 7 65.0 0x04 0x6b
100 9 10 5 4 60.0 0x09 0x34
50 7 25 15 9 64.0 0x07 0x8e
50 9 20 12 7 65.0 0x09 0x6b
50 19 10 5 4 60.0 0x13 0x34
50 24 8 4 3 62.5 0x18 0x23
20 19 25 15 9 64.0 0x13 0x8e
20 24 20 12 7 65.0 0x18 0x6b
20 49 10 5 4 60.0 0x31 0x34
10 39 25 15 9 64.0 0x27 0x8e
10 49 20 12 7 65.0 0x31 0x6b
This table was generated using a tcl-script. Copyright © 1998-2001 Heinz-Jürgen Oertel, port GmbH All rights reserved. If you find bugs in this service, please inform oe@port.de
Figura 6 – Página gerada pelo “Site” de “Bit Timing”
Foram efectuados alguns testes mas só com os nós diferentes dos do kit, pois as duas
placas EvaBoards unicamente possibilitam a comunicação a 75Kb. Estes testes tinham
sucesso nas transmissões quando os tempos eram bem calculados para ambos os
controladores, no nosso caso o 82527 e no caso dos outros nós o MCP2510. A ligação
destes nós é descrita mais adiante neste relatório.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
20
5. Arquitectura do sistema
A arquitectura do sistema está baseada num PC, que incorpora uma placa de 8 bits com
um controlador CAN (PcNetBoard III, parte integrante do KIT) para efectuar o interface
com a rede CAN que é constituída por vários nós sendo estes, placas com os seus
respectivos controladores, entradas e saídas para controlo de sensores e actuadores. A
figura seguinte ilustra esta arquitectura:
Servidor
Computador
Pessoal
PcNetBoard III
Computador
Pessoal
INTERNETPC Portátil
Barramento CAN
Nós de
CAN
Sensores e actuadores
Figura 7 – Arquitectura do sistema
5.1. Escolha das linguagens de programação
Perante os objectivos delineados, algumas escolhas tiveram de ser feitas em relação ao
decorrer do projecto. Estas referem-se à escolha do servidor Web, à linguagem de Script
e à linguagem de programação a utilizar.
Quanto à linguagem de programação da aplicação escolhemos o C, visto que todo o
código disponibilizado se encontra escrito em C, o que facilita a sua reutilização.
Utilizamos o Borland Turbo C++ v1.01 e o Borland C++ v5.0, como compiladores.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
21
No que se refere à linguagem de Script surgiram-nos duas opções: o recurso a CGI
(Common Gateway Interface) ou ao PHP (Professional Home Page tools). Depois de
algum debate escolhemos o PHP devido às enormes potencialidades que apresenta, à
facilidade de programação, às possibilidades de expansão futura, e a uma anunciada
menor utilização de recursos em relação a uma script CGI.
À junção final entre a aplicação e o PHP optámos por criar executáveis em C, a que são
passados argumentos. Esta opção permite utilizar o programa como utilizadores locais e
testar o programa, sem se estar sujeito às falhas da rede ou do servidor.
5.2. Escolha do servidor
A escolha do Servidor Web revelou-se relativamente simples, tendo optado por um
software que possibilita o uso de PHP: o OmniHTTPD da firma Canadiana Omnicron
Technologies Corporation. Este servidor foi desenvolvido para o Windows9x/NT e utiliza
funcionalidades de 32-bits e multi-operação. Suporta o PHP, a segurança em directorias,
a norma HTTP/1.1, a execução de CGI e está livre de qualquer taxa ou pagamento.
5.3. Escolha da simulação
Das inúmeras possibilidades de controlo a efectuar com este sistema foi escolhida a
domótica, pois proporciona uma melhor visão e integração a nível de simulação.
É importante salientar, que o protocolo CAN não é propriamente vocacionado para a
domótica, mas uma simulação sobre domótica torna fácil a percepção da leitura e controlo
de variáveis analógicas e digitais.
5.3.1. Conceito de domótica
A Domótica é a integração de tecnologias e serviços aplicados a lares, escritórios e
pequenos edifícios, com o propósito de automatizar e obter um aumento da segurança,
conforto, comunicação e economia de energia. Por automação entende-se a capacidade
de se executar comandos, obter medidas, regular parâmetros e controlar funções de uma
casa automaticamente.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
22
6. Estrutura geral de funcionamento
O funcionamento geral do sistema, baseia-se no servidor que irá incorporar as aplicações
necessárias para comunicar com a rede CAN.
Figura 8 – Arquitectura do servidor
Estas aplicações são programas em C que funcionam com a placa PcNetBoard III,
proporcionando um interface entre a rede CAN e o utilizador. A linguagem de
programação PHP é a responsável pela execução das aplicações, assim como a
passagem e recepção de parâmetros. Os computadores clientes permitem aos
utilizadores interagir com a rede CAN, para isto o cliente efectua uma ligação ao servidor
através de um navegador Web que via HTTP acede assim à página Web neste alojada. O
navegador Web fica assim responsável pelo envio dos pacotes para o servidor, bem
como manter o utilizador (cliente) informado à medida que o servidor envia novas
actualizações. O servidor recebe os pacotes que são enviados pelo cliente, de seguida
são interpretados e se for caso disso, o servidor executa as acções solicitadas, actualiza
os ficheiros de estado e envia a resposta ao cliente. Juntamente com o servidor é usada a
Gateway CAN WWW – Projecto Final de Curso 2000/2001
23
linguagem PHP que se encarrega de receber os pacotes, executar os pedidos e enviar a
resposta se for caso disso. Os ficheiros criados integram os valores dos registos de
configuração (regs.can), assim como os valores dos últimos estados para os sensores e
actuadores (sensact.can). As aplicações criadas interagem com a placa PcNetBoard III,
conforme o solicitado pelo cliente.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
24
7. Estruturação do software
O software criado para controlar a rede está estruturado em várias aplicações, cada uma
com uma função específica, como mostra a figura seguinte:
Figura 9 – Estruturação de compilação dos programas
Estas aplicações interagem com a placa PcNetBoard III, para inicializar o controlador
CAN, visualizar os valores das mensagens recebidas e enviar mensagens para o
barramento CAN. A descrição dos ficheiros, bem como a estruturação de cada programa
é feita a seguir.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
25
Ficheiro Descrição
ime_acc.c Implementa funções básicas de escrita e
leitura na RAM do 82527
CANfunc.c Funções necessárias a várias aplicações
ime_acc.h Contém os protótipos das funções, bem
como algumas definições
CANfunc.h Contém os protótipos das funções
ecanreg.h Atribui nomes, como constam da datasheet,
às posições de memória usadas
CANinic.c Código para inicialização
CANenv.c Código para o envio de mensagens
CANrcb.c Código para o recepção de mensagens
CANrmt.c Código para envio de tramas remotas
CANvermt.c Código que gera a pagina para envio de
tramas remotas
Tabela 3: Ficheiros envolvidos nas aplicações
O código fonte de todos os ficheiros está apresentado em anexo.
7.1. Descrição das funções
7.1.1. Funções implementadas em “ime_acc.c”
Funções Descrição
unsigned char Hex2Int (unsigned
char *StrP, unsigned int *IntP,
unsigned char l);
Converte um valor em hexadecimal para
decimal; não é uma função genérica
unsigned char CanRamValue
(unsigned int address);
Efectua a leitura do valor do
barramento CAN.
void WriteCanRam (unsigned char
address, unsigned char value);
Escreve um valor para o barramento
CAN.
unsigned char reset_can_soft
(void);
Efectua um reset por software ao
controlador CAN.
unsigned char ResetCanHard
(void);
Efectua um reset por hardware ao
controlador CAN.
Tabela 4: Descrição das funções implementadas em “ime_acc.c”.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
26
7.1.2. Funções implementadas em “CANfunc.c”
Este bloco de código implementa a maior parte das funções, usadas nos outros blocos de
código. Funções essas que passamos a descrever :
Funções Descrição
char *ctobin(int val,char *str) Converte um número inteiro numa string
(código de Niels Neibecker)
void leds(char leds[7])
Cria numa página Web uma representação,
com recurso a duas imagens, de uma fila
de leds que simbolizam a representação
binária da mensagem enviada
void barra(char leds[7],
unsigned char id, unsigned char
ext)
Idêntica à anterior, mas com a
representação de uma barra percentual.
Utiliza 8 imagens
unsigned char
get_Can_Status(void)
Lê o Status Register do 82527 e retorna
o seu valor
void touch_Can_Status(void)
Provoca a actualização do Status
Register e imprime o seu conteúdo na
página
void check_Can_error(char errcod
)
Verifica se ocorreu algum erro no envio
da mensagem, produzindo um aviso de
erro na página Web
void Transmit (unsigned char
tx_value) Transmite a mensagem pretendida
void wr_sensact(unsigned char
data[],unsigned char
arb[],unsigned char mcr)
Função desenvolvida para a simulação de
Domótica. Escreve, para determinados
identificadores, o valor enviado num
ficheiro (sensact.can)
unsigned char Hex1Int(char
*StrP, unsigned int *IntP, int
l)
Converte Hexadecimais em Inteiros; NÃO
é uma função genérica
Tabela 5: Descrição das funções implementadas em “CANfunc.c”.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
27
7.2. Descrição dos “headers”
Os ficheiros “ime_acc.h” e “CANfunc.h” correspondem aos “Headers” que englobam os
protótipos das funções acima descritas, e o “ecanreg.h” integra os nomes atribuídos às
posições de memória usadas, para assim serem usados na aplicação de controlo da
placa do PC (PcNetBoard III).
7.3. Descrição das aplicações “executáveis”
Tendo como ponto de partida, o código fonte do programa PcNet desenvolvemos 5
aplicações, descritas na tabela seguinte:
Aplicação Descrição
Inicializa Inicializa o controlador da placa
PcNetBoard III do PC
Envia
Envia mensagens de 1 a 8 bytes com
qualquer identificador, quer em modo
estendido quer standard
Recebe Recebe mensagens de todos os
identificadores configurados
VeRemota Determina quais os objectos mensagem
que estão a receber, e cria um form (html)
Rmt
Envia tramas remotas de um objecto
mensagem configurado para a recepção de
mensagens
Tabela 6: Descrição das aplicações.
As aplicações criadas partilham os ficheiros de armazenamento de dados. Assim, o
programa “Inicializa” analisa o ficheiro “regs.can” que incorpora os registos de
configuração dos registos do 82527, que é criado por um interface (Form) para configurar
o controlador com os valores desejados. Este interface será descrito mais adiante. Ambos
os programas “recebe” e “envia”, usam o ficheiro “sensact.can” para guardar o estado
actual da simulação.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
28
7.3.1. Inicializa - CANinic.c
Esta aplicação destina-se essencialmente a efectuar uma inicialização da placa
PcNetBoard III, atribuindo aos endereços específicos o valor inicial desejado, a figura
seguinte representa o modo de funcionamento.
Figura 10 – Funcionamento da aplicação “inicializa”
O ficheiro “regs.can” inclui os valores estabelecidos por default para os registos de
configuração do controlador. Caso seja necessário uma nova configuração, esta deverá
ser inserida por um interface especial, que actualiza o ficheiro de registos. A aplicação
começa por ler o ficheiro de registos, de seguida é efectuado um reset ao controlador
CAN e a memória inicializada. O valor do registo de controlo é configurado permitindo o
acesso do CPU ao resto dos registos de configuração. Os restantes valores são
configurados nos respectivos endereços preparando as objectos mensagem, para o seu
respectivo modo de funcionamento. No final é feito um ciclo de recepções para cada um
dos endereços configurados de modo a evitar os zeros iniciais e a apresentar o valor se
este for diferente de zero.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
29
7.3.2. Envia - CANenv.c
Este programa recebe os seus parâmetros da seguinte forma:
Envia data=XX,XX,XX,XX,XX,XX,XX,XX id=YY,YY,YY,YY mcr=ZZ
onde XX,YY e ZZ representam valores Hexadecimais com dois dígitos.
O programa recebe a mensagem a enviar como "data", o identificador como "Id" e o valor
a atribuir ao registo Message Configuration Register como "mcr". Este tem a seguinte
estrutura:
7 6 5 4 3 2 1 0
DCL Dir Xtd Reserved
r w r w r w R
Tabela 7: Estrutura do Message Configuration Register
Permite definir o comprimento dos dados (DLC - Data Length Code), a direcção do
objecto mensagem (Dir - Direction) e se o modo do identificador (Xtd - Extended or
Standard identifier). Os nomes dos parâmetros de entrada foram escolhidos de acordo
com a DataSheet do 82527. O tamanho de mensagem pode variar entre 1 e 8 bytes e o
identificador pode ser em modo estendido ou standard. Os bytes não utilizados devem ser
preenchidos a zero. A figura seguinte apresenta o modo de funcionamento.
Figura 11 – Funcionamento da aplicação “envia”
Gateway CAN WWW – Projecto Final de Curso 2000/2001
30
7.3.3. Recebe - CANrcb.c
Esta aplicação destina-se a receber as mensagens enviadas através do barramento CAN,
para todos os endereços previamente configurados. A função responsável pela recepção
das mensagens está implementada nesta parcela de código.
A figura apresenta o modo de funcionamento.
Figura 12 – Funcionamento da aplicação “recebe”
A aplicação começa por abrir o ficheiro “sensact.can”, lendo assim o estado anterior dos
sensores e actuadores. De seguida, verifica para cada objecto mensagem se foi
configurada para recepção, e é então efectuada a recepção do valor para o respectivo
objecto mensagem, se este for efectivamente recebido, isto é, se a “flag” de recepção do
controlador for activada, caso contrário mantém o valor anterior. Os valores recebidos são
enviados para o cliente e guardados de novo no ficheiro.
7.3.4. VeRemota - CANvermt.c
Este programa determina quais os objecto mensagem que estão configurados para
receber, lendo os registos de configuração de cada um e produz uma página Web, com
um form que permite o envio de tramas remotas para esses objecto mensagem.
Deste form consta o número do objecto mensagem (os objectos mensagem são
numerados de 1 a 15 de acordo com o Datasheet do 82527), e o identificador para o qual
Gateway CAN WWW – Projecto Final de Curso 2000/2001
31
está configurado. Este form , invoca o “rmt.php” que por sua vez, executa o programa
“rmt.exe” do qual o código é descrito a seguir.
7.3.5. Rmt - CANrmt.c
Permite o envio de tramas remotas. Recebe como parâmetro o número do objecto
mensagem preparado para receber do qual se pretende enviar a trama remota.
rmt obj=X
onde X é o numero em hexadecimal do objecto mensagem.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
32
8. Estrutura da página WEB
A estrutura da página WEB está dividida em módulos, sendo cada um deles uma
apresentação do trabalho desenvolvido ao longo deste projecto. Para uma melhor
percepção desta estrutura é apresentado mais adiante o mapa do site onde se podem
identificar os vários módulos. Foi criado um menu que interliga estes módulos, para assim
tornar fácil a navegação pela página WEB. A página de entrada para cada módulo é
apresentada na figura seguinte:
Figura 13 – Menu de interligação dos módulos
Cada módulo é chamado através do menu e incorpora interfaces (forms) específicos para
a acção que o cliente quiser efectuar, estes interfaces são descritos mais adiante.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
33
8.1. Mapa do site
Página Inicial
Página de ajuda
Entrar
index.html
./gatewaycan/index2.html
ajuda.html
Evolução ./evolucao
Primeira evolução da recepção das Evaboards recebe.php
Recepção e envio a 125Kb recenv125.html
Inicializa o controlador com os respectivos registos init.php
Modo de monitorização e envio de mensagens envia.php e monitoriza.php
Estado dos sensores estado.php
EvaBoards ./evaboards
Envio e recepção de mensagens evaborads.html
Inicializa o controlador com os respectivos registos init.php
Modo de monitorização e envio de mensagens envia.php e monitoriza.php
Configuração ./configuracao
Registos do 82527 configura.html
Valores dos registos configura.php
Inicialização do controlador init.php
Rede CAN
Envio de mensagens
Recepção de mensagens
Tramas remotas
./envia/envia.html e envia.php
./recebe/recebe.html e recebe.php
./remota/veremota.php e remota.php
Simulação ./simulacao/simulacao.html
Planta
Icons
Recepção de valores
Actuador
planta.html
icons.html
recebe.php
actuador.php e emvia_s.php
Primeira inicilalização dos registos init.php
Figura 14 – Mapa da página Web alojada no servidor
Gateway CAN WWW – Projecto Final de Curso 2000/2001
34
8.2. Interfaces (Forms)
Estes interfaces são apresentados ao cliente, confrontando-o com a decisão de controlo
que este deseja efectuar. É importante salientar que estes interfaces requerem um
conhecimento da estrutura dos registos do controlador. Todos os forms descritos a seguir,
apresentam a estrutura de registos do controlador 82527, como consta da Datasheet
respectiva. Esta Datasheet é apresentado em anexo.
8.2.1. Configuração dos registos
Este interface é usado para configurar os registos do controlador CAN, e por sua vez gera
um ficheiro de registos (regs.can) que irá ser usado pela aplicação “inicializa”, preparando
assim o controlador para um normal funcionamento. A figura seguinte ilustra o form
criado. Devido ao hardware do servidor este form dificilmente será acedido por clientes,
assim a configuração será efectuada na máquina servidor.
Figura 15 – Interface para configuração dos registos do 82527
Gateway CAN WWW – Projecto Final de Curso 2000/2001
35
Com este form configuram-se os objectos mensagem, com o identificador e modo
pretendido para inicialização do controlador. O ficheiro (regs.can) incorpora todos os
valores em decimal dos registos configurados por este form, que no total são 125.
Os valores contidos neste ficheiro seguem a estrutura apresentada (figura 2) no mapa de
endereços do 82527, onde cada um dos endereços é representado por um byte e o valor
decimal desse byte, irá ser o armazenado no ficheiro.
8.2.2. Envio de mensagens
Este form possibilita o envio de mensagens para qualquer identificador, sendo ele
estendido ou standard, podendo os dados terem de 1 a 8 bytes. Como mostra a figura, os
campos Arbitration X referem-se ao identificador, que se for estendido será do bit “ID1”
até “ID28”, e se for standard será do bit “ID18” até “ID28”. A escolha entre os modos de
identificador é feita no campo Message Configuration Register através do bit “Xtd”, neste
campo pode-se também configurar o tamanho dos dados através dos 4 bits “DLC”, onde
os valores possíveis são de 0 a 8 correspondendo aos 0 a 8 bytes de dados. Por fim,
temos os dados onde se encontram os bytes, a preencher com o valor desejado em
hexadecimal.
Figura 16 – Interface para envio de mensagens
Gateway CAN WWW – Projecto Final de Curso 2000/2001
36
8.2.3. Recepção de mensagens
Este form é basicamente idêntico ao anterior, mas com a particularidade de ser para
recepção de mensagens, onde é necessário especificar o identificador, o modo e o
número de bytes de dados a receber. A resposta deste form será o valor recebido para o
identificador pretendido, em decimal, binário e hexadecimal.
Figura 17 – Interface para recepção de mensagens
Ao efectuar a recepção das mensagens para um dado identificador, a aplicação analisa
quais os objectos mensagem que estão configuradas para recepção, e numa delas faz a
recepção das mensagens atribuindo aos registos os valores especificados. Assim os
registos do controlador relativos ao identificador ficam alterados, o que implica que ao
deixar este form seja necessário inicializar os registos do controlador para uma nova
utilização.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
37
8.2.4. Envio de tramas remotas
O que se pretende com este form é o envio de tramas remotas para um dado
identificador, ou seja, mensagens sem o conteúdo de dados. Para isso, são analisados os
registos do controlador para se identificar os objectos mensagem preparados para
recepção, sendo de seguida criada uma tabela que possibilita a escolha do identificador
para envio de entre os configurados.
Figura 18 – Interface para envio de tramas remotas
O envio de tramas remotas é usado para que um nó na rede CAN, envie os dados
relativos ao identificador requerido.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
38
8.3. Programação em PHP
Os programas em PHP vão ser os responsáveis pela aquisição dos dados, passando-os
para as aplicações e por fim enviando os resultados ao cliente que efectuou o pedido.
Seguindo a estrutura apresentada no mapa do site, temos os nomes de todos os ficheiros
“PHP” envolvidos. Para cada um dos módulos a descrição dos ficheiros é apresentada a
seguir. O código fonte destes ficheiros é apresentado em anexo.
Init.php
Existem 2 ficheiros para inicialização da placa, um deles invoca a aplicação “Inicializa” com os 4 identificadores a 75Kb/s e o outro a 125Kb/s. Esta aplicação abre o ficheiro (regs.can), para assim configurar os registos com os valores específicos.
Recebe.php Monitoriza os 4 identificadores chamando a aplicação “Recebe” e apresenta os valores recebidos em decimal, binário, hexadecimal e uma barra de leds a ilustrar o valor binário.
Envia.php
Este ficheiro é responsável por fazer a aquisição dos dados a enviar e para que identificador (dos 4 possíveis para as placas), de seguida passa estes parâmetros à aplicação “envia” que se encarrega de enviar os dados, retornando uma resposta se a mensagem foi ou não bem enviada. Caso existam erros no envio ilustra o erro que encontrou no barramento.
Monitoriza.php
Efectua a recepção de mensagens para o identificador especificado pelo cliente (dos 4 possíveis para as placas), apresentando o valor em decimal e através de uma barra percentual. Faz uma actualização dos valores recebidos de 5 em 5 segundos .
Evo
luçã
o
Estado.php
Este ficheiro apresenta os valores recebidos das variáveis de simulação que serão descritas mais à frente. Estes valores em decimal são os sensores e actuadores escolhidos para representarem a simulação de domótica. No final é apresentada a hora da última actualização referente à hora da máquina servidor.
Tabela 8: Descrição dos ficheiros “php” para o módulo Evolução
Init.php Inicializa o controlador invocando aplicação que configura os registos para o controlo das placas com os respectivos identificadores.
Envia.php Envia as mensagens com o valor e o para o identificador (dos 4 possíveis para as placas ) que foi escolhido pelo cliente.
Eva
Bo
ard
s
Monitoriza.php
Monitoriza o valor recebido para um dado identificador especificado pelo cliente, apresentando esse valor em decimal e na forma de barra percentual. Faz uma actualização dos valores recebidos de 5 em 5 segundos .
Tabela 9: Descrição dos ficheiros “php” para o módulo EvaBoards
Gateway CAN WWW – Projecto Final de Curso 2000/2001
39
Configura.php
Este ficheiro recebe os parâmetros do form configuração dos registos e cria o ficheiro dos registos (regs.can), que irá ser usado pela aplicação “inicializa”, configurando o registos do controlador com os valores contidos no ficheiro.
Co
nfi
gu
raçã
o
Init.php
Quando se altera o ficheiro dos registos é necessário fazer uma nova inicialização para o controlador estar preparado para o modo pretendido, para isso este ficheiro executa a aplicação para inicializar o controlador.
Tabela 10: Descrição dos ficheiros “php” para o módulo Configuração
envia.php
Recebe os parâmetros do form envio de mensagens e executa a aplicação “Envia” enviando assim a mensagem pretendida para o identificador especificado. Este ficheiro envia qualquer valor de dados de 1 a 8 bytes para qualquer identificador seja standard ou estendido.
recebe.php
Recebe os parâmetros do form recepção de mensagens e executa a aplicação “Recebe” recebendo assim a mensagem pretendida para o identificador especificado. Como no ficheiro anterior este recebe mensagens de qualquer identificador para um tamanho de dados de 1 a 8 bytes.
Veremota.php Invoca a aplicação “VeRemota”, sendo esta que lê os registos e verifica quais os objectos mensagem que estão preparados para recepção gerando assim um form para envio de tramas remotas.
Red
e C
AN
Remota.php Usado em conjunto com o anterior este ficheiro invoca a aplicação “Rmt” que envia a trama remota para o identificador pretendido.
Tabela 11: Descrição dos ficheiros “php” para o módulo Rede CAN
Recebe.php
Invoca a aplicação “recebe” que efectua a recepção de valores dos sensores apresentando o estado ou valor do sensor em questão. Apresenta todos os valores dos sensores bem como os valores dos actuadores, tais valores estão armazenados no ficheiro (sensact.can) e são actualizados, conforme a aplicação fizer ou não a aquisição dos dados para os identificadores associados aos sensores e actuadores. Para uma melhor percepção do funcionamento da rede, apresenta também o “CANStatus” analisando eventuais erros na rede e a data e hora da última actualização.
Actuador.php
Este ficheiro receber os parâmetros que identificam que actuador vai ser actuado, passando-os para o ficheiro “Envia_s.php”. Com estes parâmetros, calcula-se ainda a qual a mensagem que deve ser enviada para alterar o actuador sem afectar os restantes. O objectivo é criar uma página com uma acção específica para cada actuador (ligar ou desligar), verificando qual o valor que consta no ficheiro ”sensact.can”.
Sim
ula
ção
Envia_s.php
Recebe os parâmetros que são passados ao ficheiro “Actuador.php”, mais o valor da mensagem a enviar que permite alterar o actuador pretendido, sem alterar os restantes. Este ficheiro invoca a aplicação “Envia” passando-lhe os parâmetros que recebe e preenchendo os restantes com valores predefinidos.
Tabela 12: Descrição dos ficheiros “php” para o módulo Simulação
Gateway CAN WWW – Projecto Final de Curso 2000/2001
40
8.4. Programação em HTML
A programação em HTML são todos aqueles ficheiros que ajudam na estruturação da
página WEB, tais como os que idealizam a arquitectura de frames para melhor
percepção, ou os que simplesmente incorporam informação e os que chamam os
ficheiros “PHP” para execução das aplicações.
Um pormenor importante a realçar é a maneira como a informação é mantida actualizada
no cliente. Todas as páginas que participam na monitorização da rede CAN possuem uma
instrução HTML que obriga à actualização da página decorrido um determinado período
de tempo previamente estipulado. Desta forma o utilizador não necessita de realizar
nenhuma acção para obter a informação actual.
Assim, recorrendo somente ao HTML conseguimos uma monitorização da rede que se faz
de forma automática aos olhos do utilizador, através de uma página Web simples.
O mapa do site ilustra os nomes dos ficheiros envolvidos, dos quais é apresentado o seu
código fonte em anexo.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
41
9. Simulação com os nós X e Y
Para que o projecto não fique limitado à utilização do “kit I+Me” foram introduzidos na
rede nós de CAN desenvolvidos por outro projecto, a que chamaremos nós X e Y ficando
os nós do kit designados como nós A e B.
9.1. Objectivos
Os objectivos que se pretendem atingir com esta simulação é testar esta gateway numa
situação de controlo à distância em que a variação temporal dos tempos de transmissão
na rede TCP/IP não afectem de forma critica o desempenho do sistema controlado.
9.2. Atribuição de identificadores
Os identificadores (em hexadecimal) das mensagens referentes aos sensores e
actuadores da simulação foram atribuídos como está apresentado na tabela seguinte;
esta mostra também a designação do sensor ou actuador, o modo do identificador e a
linha correspondente no ficheiro “sensact.can”. Assim, a titulo de exemplo, a informação
recebida numa mensagem com identificador 000 em modo standard será colocada na
linha um do ficheiro.
Nó Sensores Modo ID (HEX) Linha no ficheiro
Y Incêndio Standard 000 1
Y Intrusos Standard 001 2
Y Inundação Standard 002 3
X Temperatura Standard 003 4
Y Humidade (Jardim) Standard 004 5
A Luminosidade Estendido 0040000 6
Y Correio Standard 005 7
Nó Actuadores Modo ID (HEX) Linha
X Iluminação exterior/Rega Standard 006 8
Y Iluminação interior 1 Standard 007 9
X Iluminação interior 2 Standard 008 10
B Ventoinha (cozinha) Estendido 0000000 11
Tabela 13: Descrição dos identificadores atribuídos
Gateway CAN WWW – Projecto Final de Curso 2000/2001
42
O tamanho dos dados na simulação será de um byte e os bits usados para controlar cada
um dos sensores e actuadores são descritos a seguir. Optamos por atribuir um byte a
cada sensores e codificar os diferentes actuadores, a excepção da ventoinha, usando
diferentes bits de um byte para controlar diferentes actuadores de determinado grupo. Por
exemplo ao grupo de actuadores “Iluminação interior 2” correspondem a iluminação da
Sala, Quarto, Escritório e Cozinha, sendo cada actuador controlado por determinado bit
da mensagem (byte) enviada com o identificador standard 008.
Byte de dados Sensores Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0 Incêndio X X X X X X Dados X Intrusos X X X X X Dados X X
Inundação X X X X X X X Dados Temperatura Dados Dados Dados Dados Dados Dados Dados X
Humidade (Jardim) X X Dados Dados X X X X Luminosidade Dados Dados Dados Dados Dados Dados Dados Dados
Correio X X X X Dados X X X Actuadores Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0
Ilumin. exterior/Rega X X X X Rega IExt X X Iluminação interior 1 X X X X Esc Cozi WC1 WC2 Iluminação interior 2 X X X X X X Quarto Sala Ventoinha (cozinha) Dados Dados Dados Dados Dados Dados Dados Dados
Tabela 14: Descrição dos Bits usados
Os bits assinalados (para actuadores de iluminação) funcionam com lógica invertida, ou
seja “zero” corresponde a activo e “um” a inactivo.
9.3. Interface de Simulação
Para executar uma acção nos actuadores basta “clicar” sobre a figura no ícone
correspondente, e aparecerá no canto inferior direito a acção possível para esse
actuador. O sistema de alarmes pode ser desligado através do botão ”Sistema de
alarmes” onde é necessário introduzir uma password para o efeito. O estado e valor dos
vários sensores e actuadores são apresentados do lado direito deste interface, sendo
actualizado de 5 em 5 segundos, automaticamente.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
43
Figura 19 – Interface de Simulação
9.4. Adaptação das EvaBoards à simulação
Para a implementar a simulação usámos as placas EvaBoard de forma a que uma
representa um sensor e outra um actuador, respectivamente o sensor de luminosidade e
a ventoinha. Para representar o sensor, utilizámos o reóstato que está presente numa das
placas de ligação DIN41612. Para activar a ventoinha usámos um sinal PWM, presente
na placa de ligação com o amperímetro, ao qual condicionámos um pequeno circuito,
nomeadamente um par de Darlington, com que alimentámos uma ventoinha duma fonte
de alimentação dum PC (12V e 0.13 A).
Gateway CAN WWW – Projecto Final de Curso 2000/2001
44
10. Futuros desenvolvimentos
Neste ponto deixamos algumas ideias para o desenvolvimento e continuação deste
trabalho.
10.1. Base de dados dos movimentos importantes na rede
Um problema que acompanhou a realização deste projecto, prende-se com o facto de que
em termos temporais as duas redes envolvidas serem bastantes diferentes. Se no CAN
temos tempos de transmissão que se mantêm constantes, numa rede TCP/IP tal não
acontece.
Isto conduz a situações em que na rede CAN nós (ou actuadores) mudam de estado
demasiado depressa, para que seja acompanhada por uma ligação TCP/IP convencional.
Tal facto poderá ser resolvido, se fizermos a monitorização da rede, não directamente
mas sim através de uma base de dados que seria actualizada no servidor. Desta forma
eliminaríamos a possibilidade de determinada acção, levada a cabo na rede CAN, não ser
reportada à página Web de monitorização.
10.2. Software das EvaBoards
Outra acção que poderá ser realizada é o desenvolvimento de software para as placas
EvaBoard. O software que as EPROM’s (27c256 da Microship) trazem de fábrica não
aproveitam a totalidade dos recursos disponibilizados pelas placas.
10.3. Desenvolver Periféricos para ligação às EvaBoards
No seguimento da proposta anterior, poderiam ser desenvolvidos periféricos mais
complexos para as placas, visto que elas disponibilizam a totalidade dos pinos do
C167CR-LM através de um ligador DIN 41612 de160 pinos.
10.4. Desenvolver uma aplicação cliente/servidor
Uma outra aproximação a este projecto seria desenvolver uma aplicação numa linguagem
orientada a objectos, tal como o Java, que integrasse todas as funções, que na nossa
aproximação são implementadas por diferentes linguagens (C e PHP) . Possivelmente tal
aplicação seria mais compacta e traria uma melhoria no desempenho geral do sistema,
Gateway CAN WWW – Projecto Final de Curso 2000/2001
45
nomeadamente na ligação cliente/servidor. Esta ligação poderia ser implementada
através de uma aplicação cliente/servidor com recurso a sockets. Tal aplicação poderia
funcionar de forma independente de qualquer Internet Browser ou então com recurso a
um, usando uma Java Applet.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
46
11. Conclusões
Olhando para o início deste projecto, para os objectivos que nos propusemos alcançar e
para a forma como resolvemos abordar a proposta do Professor Artur Cardoso,
constatámos uma evolução substancial na nossa maneira de encarar e enfrentar os
problemas, contribuindo para a nossa preparação como Engenheiros.
O nosso projecto proporcionou-nos adquirir bastantes conhecimentos sobre as Controller
Area Networks (CAN) e a forma como estas são implementadas e interagem com os
sensores e actuadores, bem como com as restantes redes em ambientes industriais. O
CAN revelou-se uma ferramenta bastante poderosa, com possibilidades de aplicação em
franca expansão e com uma implementação no mercado, que nos faz acreditar que será
futuramente a primeira escolha, para a maioria das aplicações de automação nos mais
diversos níveis. A nossa familiarização, com o CAN a um nível mais prático abrangeu o
estudo do controlador de CAN Intel 82527 e do Microcontrolador Siemens C167CR-LM,
ambos usados neste projecto.
Proporcionou-nos também alargar os nossos conhecimentos numa linguagem: o C, que
apesar dos anos se tem mantido relativamente actual, sendo uma grande escola para
aprofundar conhecimentos de programação. Sendo sem dúvida uma linguagem que não
foi pensada para aplicações na Web, é com grande facilidade que se adapta a este novo
meio, mantendo ainda assim a característica que a tornou famosa, a sua robustez.
Em conjunto com o C, e em estreita ligação com este, usamos o PHP que se revelou uma
linguagem bastante versátil, de fácil utilização e aprendizagem. Sendo uma linguagem
script relativamente recente e em constante evolução mostrou ter atributos que, para as
aplicações por nós desenvolvidas, fica subaproveitada, mas revelando-se de grande
eficiência e eficácia para tudo o que lhe foi requisitado.
A arquitectura para a Gateway por nós escolhida: ligação da rede CAN à Internet via um
conjunto de páginas HTML alojadas no servidor HTTP, permitiu-nos abstrair
substancialmente do protocolo TCP/IP, mas não ignorá-lo. As características deste
aparecem como características da Internet, que o tem como suporte. Assim
características da Internet como a variação dos tempos de transmissão, e a
unilateralidade do modelo cliente/servidor foram estudadas para o desenvolvimento das
aplicações.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
47
Ganhámos também conhecimentos alargados em aplicações de controlo via Web,
durante as pesquisas que realizámos, quer em busca de informação sobre o CAN e as
suas aplicações quer na busca de um tema para a simulação realizada. É sem dúvida
uma utilização da Web que os seus criadores, quer consideremos a equipa da Advanced
Research Projects Agency Network (ARPANET) quer consideremos Tim Berners-Lee e
Robert Cailliau do Cern, dificilmente poderiam imaginar quando desenvolveram os seus
projectos, mas que se tem vindo a difundir rapidamente. A facilidade de utilização e a
rápida expansão da Web leva a que seja vista, como terreno fértil para todo o tipo de
controlo remoto, quer seja simplesmente fechar um estore quer seja controlar
completamente uma grande unidade fabril. Isto leva-nos a pensar que o trabalho
realizado poderá em grande medida ser utilizado por outros alunos finalistas como ponto
de partida para irem mais longe no aprofundamento destas questões.
Fazendo uma auto-avaliação geral a todos os aspectos presentes neste trabalho, tendo
nós adquirido conhecimentos em diferentes áreas da engenharia e chegado a uma
solução final funcional que cumpre com o estipulado pelo objectivos, somos levados a
dizer, que do nosso ponto de vista, foi sem dúvida um trabalho conseguido, e que apesar
do esforço que exigiu, este foi em larga medida compensado.
Não poderíamos terminar sem deixar uma palavra de agradecimento ao Professor Artur
Cardoso, orientador deste trabalho pela disponibilidade demonstrada e por todo o apoio
que nos prestou ao longo deste trabalho.
Gostaríamos também de agradecer aos colegas Pedro Caldeira e Roberto Fernandes
pelo apoio e colaboração prestados, não só no decorrer da parte comum dos nossos
projectos, mas durante toda a duração deste.
Gateway CAN WWW – Projecto Final de Curso 2000/2001
48
Bibliografia e referências:
• Peneda, Carlos e Oliveira, Pedro. Projecto de um nó de uma rede CAN. L.E.E.C-
F.E.U.P. Junho, 2000.
• Deitel, H.M. e Deitel, P.J. C How to program Second Edition. Prentice Hall, 1993.
• Damas, Luis. Linguagem C 3ª Edição. FCA – Editora de Informática, Janeiro 1999.
• Papas, Chris H. e Murray, William H. Tradução Fecchio, Mário Mono. Turbo C++
Completo e Total. McGraw-Hill, 1991.
• Powell, Thomas A. HTML: The Complete Reference. McGraw-Hill, 2001.
• Serrão, Carlos e Marques, Joaquim. Programação com PHP. FCA – Editora de
Informática, Setembro 2000.
• Bosch, Robert GmbH. BOSCH CAN Specification Version 2.0. Setembro, 1991
• Bagschik, Peter, An Introduction to CAN, [http://www.ime-actia.com ]
• Nilsson, Staffan, Controller Area Network - CAN Information. Junho, 1997.
[http://www.algonet.se/~staffann/developer/CAN.htm]
• E-947 Tópicos Especiais em Automação Industrial, Escola Federal de Engenharia
de Itajubá, Junho, 1998.