relatório do projecto final de cursoee99058/projecto/relatorios/relatorio_g.pdf · gateway can www...

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.


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.


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.


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.


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;


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


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.


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.


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.


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.


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.


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.


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


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;


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.


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 [email protected]

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.


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.


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.


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


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.


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.


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”.


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”.


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.


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.


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”


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


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.


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.


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


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


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


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.


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.


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


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


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.


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


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.


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).


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,


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.


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.


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.


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.

relatório do projecto final de cursoee99058/projecto/relatorios/relatorio_g.pdf · gateway can www...

Documents