Leandro Toldo de Souza
Implementação de um gateway para
conversão do protocolo CAN para o
modelo SystemC TLM
Florianópolis
2017
Resumo
Com cada vez mais dispositivos embarcados nos au-tomóveis, tornou-se necessário criar protocolos para organizar o trânsito de dados e o acesso aos mesmos. Neste contexto surge o protocolo CAN (Controller Area Network) um dos mais utilizados na área automotiva, cuja principal característica está na sua confiabilidade. Este trabalho propõe a implementação de um gateway para converter pacotes do protocolo CAN para paco-tes SystemC TLM e vice-versa para poder usá-lo em simulações de software.
Abstract
With more and more devices being loaded onto cars, it became necessary to create protocols to organize data traffic and access them. In this context, the CAN (Con-troller Area Network) protocol is one of the most used in the automotive area, whose main characteristic lies in its reliability. This work proposes the implementation of a gateway to convert packets from the CAN protocol to SystemC TLM packets and vice-versa in order to be able to use it in software simulations.
Lista de ilustrações
Figura 1 – Composição de uma rede CAN. . . . 22
Figura 2 – Diagrama de blocos de um nó CAN. 23
Figura 3 – Pacote de dados na formatação do protocolo. . . 26
Figura 4 – Frame utilizado durante a fase de arbitração.. . . 26
Figura 5 – Exemplo de fase de arbitração. . . . 27
Figura 6 – Proposta de topologia. . . 32
Figura 7 – Fluxo de inicialização. . . 33
Figura 8 – Fluxo de envio de mensagem. . . 34
Figura 9 – Arquitetura do trabalho desenvol-vido pelo autor. . . 35
Figura 10 – Máquina de estados do controlador no modo de envio. . . 36
Figura 11 – Máquina de estados do controlador no modo de recepção. . . 37
Figura 12 – Arquitetura do hardware virtualizado. 37
Figura 13 – Latências das simulações comparando a virtualização com a implementação em hardware. . . 38
Figura 14 – Fluxograma do desenvolvimento do projeto. . . 42
Figura 15 – Topologia do projeto.. . . 43
Figura 16 – Características do módulo CANCon-trol. . . 48
Figura 17 – Máquina de estados da unidade de controle. . . 49
Figura 18 – Características da unidade de con-trole ControlUNIT. . . 54
Figura 19 – Máquina de estados da unidade de controle. . . 55
Figura 20 – Características do módulo TLM Tar-get. . . 56
Figura 21 – Características da unidade de con-trole ControlUNIT. . . 57
Figura 22 – Características do simulador de pro-cessador Initiator.. . . 58
Lista de tabelas
Tabela 1 – Campos do quadro de mensagem do pacote CAN e seus respectivos tama-nhos em bits. . . 25
Tabela 2 – Casos de simulação mostrados, o ta-manho dos frames está em bits, en-quanto o dos dados está em bytes. . 60
Tabela 3 – Latência das transações Processador-Memória, Memória-Unidade de con-trole, Unidade de controle-Controlador, Controlador-Barramento, com o tempo em nano segundos. . . 61
Tabela 4 – Latência das transações Barramentro-Controlador, Controlador-Unidade de controle, Unidade de controle-Memória, Memória-Processador, com o tempo em nano segundos. . . 61
Sumário
1 INTRODUÇÃO . . . 15 1.1 Objetivo . . . 17 1.1.1 Objetivo Geral . . . 17 1.1.2 Objetivos específicos . . . 17 1.2 Motivação . . . 18 2 O PROTOCOLO CAN . . . 21 2.1 Redes CAN . . . 21 2.2 Características físicas . . . 242.3 Formatação de dados CAN . . . 25
2.4 Fase de arbitração . . . 26 2.5 Detecção de erros . . . 28 2.5.1 Bit stuffing . . . 28 2.5.2 CRC. . . 28 3 TRABALHOS RELACIONADOS. 31 4 DESENVOLVIMENTO . . . 41 4.1 Projeto. . . 43 4.1.1 CANControl . . . 44 4.1.2 ControlUNIT . . . 44 4.1.3 Target . . . 44
4.1.4 Bus . . . 45 4.1.5 Initiator . . . 45 4.2 Implementação . . . 45 4.3 Implementação do controlador CAN
CANControl . . . 46 4.3.1 Trecho de código do controlador . . . . 50 4.4 Implementação da unidade de
con-tole ControlUNIT . . . 53 4.5 Implementação do módulo TLM
Target . . . 55 4.6 Implementação da unidade de
pro-cessamento Initiator . . . 57 5 RESULTADOS . . . 59
6 DISCUSSÃO DE RESULTADOS . 63
7 CONCLUSÃO . . . 65
8 SUGESTÕES PARA TRABALHOS FUTUROS . . . 67
15
1 Introdução
A indústria automobilística teve início no século XVIII com os carros de motor a vapor, sendo estes ad-quiridos somente pelas pessoas de alto poder aquisitivo, assim primariamente passou a ser considerado um item de luxo. De lá para cá se passou a utilizar o motor à combustão e com a evolução da tecnologia hoje uma parcela maior da população tem acesso à automóveis, aumentando cada vez mais a competição entre as em-presas produtoras de veículos automotivos. Durante a era industrial, os principais diferenciais competitivos dos automóveis eram diretamente associados à potência do motor, design da carroceria, conforto e o preço.
Logo no começo da Era da Informação este pa-radigma se alterou um pouco. Além das características da era passada, hoje a tecnologia embarcada tornou-se um diferencial muito poderoso. Hoje, o público quando compra um carro espera não apenas um meio de se lo-comover, mas também segurança na viagem, eficiência, conforto, automatização de dispositivos e até mesmo de direção. Os sistemas embarcados tornaram-se mais do que um marketing, tornaram-se uma necessidade para
16 Capítulo 1. Introdução
se manter competitivo no mercado de automóveis no século XXI.
Os primeiros sistemas embarcados em veículos surgiram na década de 70, de lá para cá é cada vez maior o nível de automação e processamento presente nos automóveis. Primeiramente foram desenvolvidos sistemas isoladamente, para funções específicas basica-mente formadas por um microprocessador, uma rede de sensores e atuadores. No decorrer dos anos foi ne-cessário desenvolver mecanismos que possibilitassem a comunicação entre estas unidadedes de controle presen-tes nos automóveis - conhecidas também como ECU’s (Engine Control Unit) - tanto para gerar estatísticas quanto para poder atuar em diversos setores, como por exemplo, a informação referente à velocidade estimada do motor gerada pelo controlador do mesmo pode ser usada pelo controlador da suspensão para fazer ajustes na mesma.
Para gerenciar essa quantidade de sistemas tra-balhando com diferentes tipos e granularidades de dados foram desenvolvidos vários protocolos de comunicação, como o FlexRay e o CAN (Controller Area Network). O objetivo destes protocolos é uniformizar a comunica-ção, fazendo com que as informações possam transitar de maneira que todos os sistemas de interesse se
co-1.1. Objetivo 17
muniquem, independente da formatação própria dos dados.
Com o intuito do leitor compreender efetiva-mente os conceitos discutidos neste trabalho, bem como seu desenvolvimento, recomenda-se que possua noções básicas de lógicas de algoritmos para o entendimento dos mesmos, além de C/C++ para uma melhor com-preensão da implementação.
1.1
Objetivo
1.1.1
Objetivo Geral
O objetivo deste trabalho é desenvolver um ga-teway que converta dados no formato CAN para dados no formato SystemC TLM e vice-versa, a fim de poder utilizá-lo para simulações em software em ambientes de testes para a validação do funcionamento tanto do controlador quanto da arquitetura escolhida de imple-mentação.
1.1.2
Objetivos específicos
18 Capítulo 1. Introdução
• Desenvolver um conversor TLM to CAN e vice-versa;
• Descrever de maneira sucinta o protocolo CAN.
1.2
Motivação
Confiabilidade é um fator extremamente essen-cial em sistemas críticos de tempo real e dependendo do quão crítico é o sistema, uma decisão não pode ser adiada, para que isto ocorra o sistema deve ser robusto e capaz de tomar a decisão correta quando uma situação crítica acontecer. Na área automobilística, a rede CAN - nome dado devido ao protocolo de comunicação
utili-zado [2] - tornou-se uma das mais utilizadas no mundo devido ao seu alto grau de confiabilidade, simplicidade de implementação e baixo custo.
Em sistemas embarcados, podem existir proto-colos diferentes em múltiplos níveis e é necessário testar tanto a comunicação local, entre o mesmo protocolo, e intercomunicações entre protocolos diferentes. Visto deste ponto, torna-se extremamente interessante poder validar pelo menos boa parte desta comunicação através de modelagem em software, sem a necessidade de um
1.2. Motivação 19
hardware específico. Este é o papel que o SystemC TLM tem no processo de desenvolvimento.
O motivo de se utilizar SystemC TLM neste tipo de aplicação é seu fácil entendimento e implementação. Outra vantagem é a exploração arquitetural mais ampla, pela rapidez em que os módulos são implementados em software perante implementações em nível RTL, além do alto grau de abstração em relação a outras linguagens semelhantes que modelam arquiteturas de hardware [3][4], como VHDL e Verilog.
Apesar de possuírem semelhanças, as linguagens de descrição de hardware tradicionais (VHDL e Veri-log) em geral são altamente estruturadas. Sendo assim, muitos de seus códigos não são tão intuitivos a um pú-blico não familizarido com estas linguagens, enquanto a utilização de uma linguagem de programação como C++ permite atingir uma parcela maior de profissio-nais, tornando o entendimento do código bem como suas alterações mais velozes, eficientes e intuitivos[3].
21
2 O protocolo CAN
Em 1983 a BOSCH começa a desenvolver a rede CAN e após três anos, durante a conferência da So-ciedade dos Engenheiros Automobilísticos (SAE), foi lançado o protocolo CAN cuja principal característica é garantir a confiabilidade da comunicação. A primeira padronização das redes CAN veio em 1994 com a ISO 11898-1 que passou a descrever o protocolo CAN.
2.1
Redes CAN
As redes CAN são compostas pelos chamados nós, pontos por onde dispositivos podem acessar o bar-ramento de dados. A comunicação das redes CAN são feitas de maneira serial através de um barramento, fun-cionando em modo de multi master. Sendo assim a co-municação é do tipo broadcasting, onde quando qualquer dispositivo conectado à rede começa a comunicar-se, os demais sempre recebem a mensagem mesmo não sendo de seu interesse. Sendo assim, o transmissor apenas necessita saber se a mensagem chegou corretamente a pelo menos um dos receptores, de acordo com [1].
22 Capítulo 2. O protocolo CAN
Como apenas um nó pode acessar o barramento por vez, os nós mais críticos possuem prioridade no acesso, em geral estes nós estão atrelados à áreas onde a decisão impacta diretamente sobre a segurança do usuário, segundo [4]. Um exemplo disto em um ambiente automotivo é o freio ABS, o nó em que ele pertence tem prioridade sobre por exemplo, o nó ao qual pertence o DVD player.A figura 1mostra uma visão da rede com os respectivos nós.
Figura 1 – Composição de uma rede CAN. Podemos generalizar a região de um nó por 3 componentes básicos listados na figura2.
• Processador: Região onde dados do veículo são processados;
2.1. Redes CAN 23
• Controlador CAN: Região onde é feita a interface de comunicação, entre o processador e o barra-mento. O controlador altera o formato dos dados, bidirecionalmente, ou seja, o formato de dados presente no processador é convertido para o for-mato CAN e vice-versa;
• Barramento: Região onde a comunicação é feita com os dados no formato CAN.
24 Capítulo 2. O protocolo CAN
2.2
Características físicas
Como citado anteriormente, a comunicação se dá de maneira serial por um barramento, através de um par diferencial e com uma taxa de transferência de dados máxima de 1 Mbits/s com o comprimento do barramento não maior que 40 metros de acordo com o padrão. O motivo é a necessidade que a frente de onda do bit chegue ao nó mais longínquo da rede e volte ao nó de partida antes de ser amostrado. É importante ressaltar que um nível lógico dominante no barramento implica em um bit “0” e um nível lógico recessivo se refere a um bit “1” [1].
A utilização do par diferencial se faz extrema-mente efetiva uma vez que atenua as interferências que o próprio veículo gera através da rejeição do modo co-mum, como por exemplo a interferência eletromagnética que o motor causa nos demais equipamentos. Em al-guns casos em que as redes CAN são utilizadas fora do contexto de tempo real, admite-se taxas menores de transmissão, sendo assim pode haver um barramento com uma extensão maior.
2.3. Formatação de dados CAN 25
2.3
Formatação de dados CAN
Os pacotes de dados da rede CAN são dividi-dos em subpacotes com funções específicas e o pacote de dados úteis pode variar entre 55 e 111 bits, depen-dendo do tamanho da mensagem. A tabela 1 mostra uma tabela com os respectivos campos e tamanhos dos mesmos especificados pelo protocolo CAN, já na figura
3 podemos ver um exemplo de organização do quadro .
Field name Length
Start-of-frame 1
Identifier (green) 11
Remote transmission request (RTR) 1 Identifier extension bit (IDE) 1
Reserved bit (r0) 1
Data length code (DLC) 4
Data field 0-64 CRC 15 CRC delimiter 1 ACK slot 1 ACK delimiter 1 End-of-frame (EOF) 7
Tabela 1 – Campos do quadro de mensagem do pacote CAN e seus respectivos tamanhos em bits.
26 Capítulo 2. O protocolo CAN
Figura 3 – Pacote de dados na formatação do protocolo.
2.4
Fase de arbitração
Pelo padrão de comunicação ser do tipo bro-adcasting, é necessário que quando dois ou mais nós começarem uma transmissão ao mesmo tempo seja dada prioridade a um deles. Neste momento, inicia-se a fase de arbitração, onde os nós CAN começam a enviar seus bits pertencentes ao campo do identificador (ID). Os campos correspondentes a esta fase estão descritos na figura4.
Figura 4 – Frame utilizado durante a fase de arbitração. Para saber se o respectivo nó utilizará o bar-ramento em detrimento aos demais há uma operação
2.4. Fase de arbitração 27
lógica and com o barramento, sendo assim, enquanto o resultado for um nível lógico dominante, ele conti-nua enviando bit a bit seu identificador. Em caso de terminar o identificador, o restante do frame é envi-ado, caso contrário o controlador começa a observar o barramento, esperando a mensagem do vencedor da fase de arbitração. Os nós com os maiores valores de identificador (campo ID) terão prioridade no acesso ao barramento, uma vez que um bit “1” indica um nível lógico 0 e a operação “0” and “1” resulta em “0”, equi-valente ao bit “1” enviado pelo controlador de maior prioridade. A figura 5 ilustra o funcionamento da fase de arbitração.
28 Capítulo 2. O protocolo CAN
2.5
Detecção de erros
O protocolo utiliza duas técnicas de detecção de erros, que serão abordadas a seguir.
2.5.1
Bit stuffing
A primeira delas é conhecida como bit stuffing. A técnica consiste em adicionar bits artificiais entre os bits de informação com o intuito de auxiliar na sincronização ou, simplesmente detectar um erro no pacote de dados.
No caso específico das redes CAN, a técnica de bit stuffing é utilizada a cada cinco bits consecutivos com o mesmo nível lógico no frame. Quando detectado este padrão, o controlador insere um bit adicional com valor lógico invertido na mensagem logo após o evento, podendo assim aumentar significativamente o tempo de transmissão, uma vez que podemos ter um acréscimo de até 20% no tamanho do frame.
2.5.2
CRC
A outra técnica utilizada é denominada Cyclic redundancy check (CRC), desenvolvida por William
2.5. Detecção de erros 29
Wesley Peterson (22 de abril de 1924 – 6 de maio de 2009) em 1961, esta técnica tem como objetivo inserir uma redundância na mensagem para a detecção de erros, o que causa um aumento no tamanho total do frame.
Este método consiste em tratar o frame como um polinômio de grau m, deste modo, utiliza-se um outro polinômio de grau n < m, de maneira que o resultado da divisão polinomial é adicionado em n + 1-bits extras ao frame. Com isto, é possível saber se houve erros durante a transmissão, visto que, em geral é interessante utilizar um n (grau do polinômio do CRC) muito menor que m (grau do polinômio de mensagem), para que a probabilidade de que o erro ocorra no CRC seja menor que nos demais campos.
No caso de estudo, os campos codificados no CRC do protocolo CAN podem variar de 16 a 80 bits e o polinômio divisor pode ser visto na equação 2.1 [2].
31
3 Trabalhos relacionados
Gao Qiang propõe em [5] configurar microcon-troladores de maneira semelhante à redes CAN. De acordo com o trabalho descrito, o objetivo é utilizar um microprocessador para emular a rede, sem necessa-riamente ter um hardware dedicado específico, fazendo assim com que o controlador CAN possa existir em conjunto com o microprocessador diminuindo também a quantidade de cabos totais da rede.
A proposta de topologia utilizada pelos auto-res é ilustrada na figura 6. Como podemos observar, o controlador é implementado em software a partir do mi-crocontrolador P87C591, a comunicação é feita através de um opto acoplador e ainda temos um transceptor CAN, o qual apenas coleta e envia dados, mas não os processa. Neste contexto o transceptor é apenas uma interface de comunicação e não realiza o processamento em si.
Os autores propõem que o controlador apenas esteja ativo enquanto o processador desejar, sendo assim existe um fluxo de inicialização, como visto na figura 7. Isto abre a possibilidade de retirar nós ou configurar a
32 Capítulo 3. Trabalhos relacionados
Figura 6 – Proposta de topologia.
rede da maneira necessária, sendo o máximo eficiente possível em cada situação.
Uma vez inicializado, o processador pode cha-mar uma rotina de interrupção para enviar a mensagem, acionando assim o transceptor, possibilitando o envio da mensagem já nos conformes do protocolo CAN para o barramento. A figura 8 mostra o fluxograma
desen-33
Figura 7 – Fluxo de inicialização.
volvido pelos autores e executado pelo processador. Chinta [6], utiliza-se um microcontrolador como controlador CAN, e ao contrário do trabalho
anterior-34 Capítulo 3. Trabalhos relacionados
Figura 8 – Fluxo de envio de mensagem. mente citado, todo o funcionamento é feito a nível de registrador, sendo uma implementação mais em nível de hardware.
A proposta do trabalho é utilizar redes CAN numa rede de sensoriamento, a figura9 mostra a
arqui-35
tetura utilizada pelo autor.
Figura 9 – Arquitetura do trabalho desenvolvido pelo autor.
Foram realizados dois tipos de testes nestes en-saios, o primeiro apenas no modo de transmissão e o segundo apenas no modo de leitura. As figuras 10 e11
mostram a máquina de estados utilizada em cada um dos ensaios.
A proposta do trabalho de usa redes CAN em sistemas de sensoriamento e monitoramento mostra-se muito interessante, uma vez que não são necessárias
36 Capítulo 3. Trabalhos relacionados
Figura 10 – Máquina de estados do controlador no modo de envio.
taxas extremamente elevadas de dados, mas a confia-bilidade dos mesmos é de extrema importância para a tomada de decisão.
Herber [7], utiliza uma paravirtualização para simular um ambiente de teste para gateways. É utili-zado um controlador CAN como objeto de estudo, a
37
Figura 11 – Máquina de estados do controlador no modo de recepção.
arquitetura implementada pelo autor é ilustrada na figura 12
38 Capítulo 3. Trabalhos relacionados
Após diversos testes, o autor compara a latência de simulação de diversas comunicações entre os pro-cessadores e o módulo CAN. A figura 13 mostra que realizar simulações em um ambiente virtual faz com que a latência seja reduzida consideravelmente, princi-palmente em ambientes que possuam uma gama vasta de unidades e gateways para a conversão de protocolos.
Figura 13 – Latências das simulações comparando a vir-tualização com a implementação em hard-ware.
Estudando-se os trabalhos realizados, tem-se uma perspectiva muito promissora utilizar uma imple-mentação híbrida de hardware via software. Neste sen-tido a implementação do controlador em SystemC a fim
39
de explorar a arquitetura em nível de hardware, porém utilizando toda a versatilidade de software, mostra-se um caminho interessante a se seguir e baseado nisso é que este trabalho é realizado.
41
4 Desenvolvimento
O desenvolvimento do controlador seguiu basi-camente três etapas de projeto, as quais estão listadas abaixo:
• Revisão da literatura e estado da arte; • Definição dos parâmetros do projeto; • Implementação do controlador.
É importante ressaltar que apesar de uma vez definidas todas as etapas, pode ser necessário retornar a uma delas devido a um contratempo ou possibilidade de otimização. A figura 14 ilustra o fluxo proposto.
Como se pode observar, primeiramente é feita uma revisão da literatura e do estado da arte. Feito isto seguimos para o projeto. Durante a fase de projeto, escolhemos métricas e tomamos decisões acerca do que foi pesquisado para atingirmos os objetivos, feito isto caso faltem dados ou o apoio de pesquisa não seja o suficiente, retornamos ao passo anterior, caso contrário seguimos para a implementação. Na implementação executamos o projeto, caso não haja viabilidade de
42 Capítulo 4. Desenvolvimento
Figura 14 – Fluxograma do desenvolvimento do pro-jeto.
algum dos parâmetros, possibilidade de otimização ou até mesmo um erro de projeto, volta-se ao projeto, para que seja modificado e assim volte para a execução.
4.1. Projeto 43
4.1
Projeto
Após estudos, chegamos numa topologia básica de projeto onde definimos 3 estruturas centrais
• Controlador CAN “CANControl”; • Unidade de controle “ControlUNIT”; • Módulo TLM “Target’.
A figura 15 nos fornece uma visão geral da topologia e em seguida listamos as principais funcionalidades do mesmo.
44 Capítulo 4. Desenvolvimento
4.1.1
CANControl
Este módulo é a unidade transceptora do con-trolador, responsável por receber, montar, desmontar os frames recebidos e enviados. Também é responsável por checar o CRC e implementar os bits que não sejam pertencentes à mensagem (como o RTR e o bit stuf-fing). Além disto, possui uma entrada de clock externa, uma porta receptora e uma transmissora ambas conec-tadas ao barramento “Bus” além de um barramento de comunicação com a unidade de controle “ControlUNIT”.
4.1.2
ControlUNIT
Esta unidade é responsável por interfacear os dados que o transceptor “CANControl” necessita enviar ou receber. É uma interface direta entre o módulo TLM "target"e o controlador CAN “CANControl”.
4.1.3
Target
O módulo TLM “Target” é responsável por inter-facear a comunicação em TLM com a comunicação em SystemC. Esta unidade funciona como uma memória, onde os processos a nível de TLM leem e escrevem na
4.2. Implementação 45
mesma. Por uma questão de maior facilidade de imple-mentação no controle de acesso separamos a memória em duas, fazendo com que uma delas seja read only para os processos em TLM e write only nos processos de SystemC e, a segunda memória sendo seu espelho.
4.1.4
Bus
O módulo “Bus” foi criado para simular um barramento de dados, para que possamos através de simulações verificar o funcionamento do controlador em certas condições que impusermos.
4.1.5
Initiator
Por fim, temos o módulo “Initiator” que simula uma chamada em TLM de um processador. Sendo este utilizado para verificar se os dados estão salvos correta-mente na memória de “Target”.
4.2
Implementação
Após o projeto, foram implementados cada bloco e testados, primeiro separadamente e depois,
juntando-46 Capítulo 4. Desenvolvimento
os. É importante ressaltar que, como visto anterior-mente, o fluxo de projeto está sempre em constante mudança, fazendo com que cheguemos às versões finais citadas posteriormente.
4.3
Implementação do controlador CAN
CANControl
Para o correto funcionamento desta unidade, é necessário primeiramente verificar se o barramento está ocupado. Caso esteja, o controlador entra no modo de recepção, recebe os bits do frame até o último bit de CRC. Feito isto, realiza-se a verificação do mesmo e, em caso positivo é enviado um ACK para o barramento e a mensagem será aceita e salva, caso contrário a mensagem não será salva posteriormente.
Em caso de o barramento estar desocupado, verificamos se há uma mensagem vinda da unidade de controle “ControlUNIT”, em caso negativo volta-se a ler as entradas, em caso positivo partimos para a fase de arbitração. Durante a fase de arbitração, enviamos os três primeiros bits de RTR e em seguida o identificador ID. Após enviar cada bit é necessário verificar se o nível lógico presente no mesmo é igual ao enviado, em
4.3. Implementação do controlador CAN CANControl 47
caso afirmativo continuamos até o término desta fase, diz-se então que a fase de arbitração foi ganha pelo controlador. caso perca esta fase o controlador entra no modo de recepção e faz os respectivos processos do receptor.
Quando a fase é ganha, o controlador envia to-dos os seus bits até o fim do CRC normalmente. Ao término do mesmo é verificado se pelo menos um dos demais usuários conectados à rede recebeu corretamente a mensagem (através da leitura de um bit de ACK). A transmissão segue normal até o fim do quadro e caso nenhum dos demais controladores tenha enviado um sinal de ACK, é necessário fazer uma nova tentativa.
Tendo em mente estas necessidades, foi imple-mentado o módulo CANControl em SystemC, com as principais características da classe, as quais estão repre-sentadas através da figura 16.
48 Capítulo 4. Desenvolvimento
Figura 16 – Características do módulo CANControl. O controlador CAN foi implementado seguindo a lógica de funcionamento prevista na figura 17. Pri-meiramente, observamos o barramento para ver se há uma nova mensagem Em caso negativo, verificamos se a unidade de controle “ControlUNIT” possui dados a serem enviados.
4.3. Implementação do controlador CAN CANControl 49
Figura 17 – Máquina de estados da unidade de controle. Abaixo segue uma parte do código do controla-dor implementado. O trecho se refere ao momento em que um quadro recebido precisa ser lido e montado para
50 Capítulo 4. Desenvolvimento
posteriormente ser enviado ao barramento. Os detalhes do envio foram omitidos para não deixar o texto longo e complexo demais.
4.3.1
Trecho de código do controlador
Mess0 = Message0.read(); Mess1 = Message1.read(); Mess2 = Message2.read(); Mess3 = Message3.read(); Mess4 = Message4.read(); Mess5 = Message5.read(); Mess6 = Message6.read(); Mess7 = Message7.read(); I0 = ID0.read(); I1 = ID1.read(); DataLength = DLC.read();
int CANVector[47+8*DataLength];
CANVector[0] = 0; //SOF
CANVector[12] = 0; //RTR if(Request.read() == 1) { CANVector[12] = 1; } CANVector[13] = 0; //ID Ex.
4.3. Implementação do controlador CAN CANControl 51 // DataLength CANVector[15] = 0; CANVector[16] = 0; CANVector[17] = 0; CANVector[18] = 0; //CRC is 0x4599 for CAN CANVector[19+8*DataLength] = 0; CANVector[20+8*DataLength] = 0; CANVector[21+8*DataLength] = 0; CANVector[22+8*DataLength] = 0; CANVector[23+8*DataLength] = 0; CANVector[24+8*DataLength] = 0; CANVector[25+8*DataLength] = 0; CANVector[26+8*DataLength] = 0; CANVector[27+8*DataLength] = 0; CANVector[28+8*DataLength] = 0; CANVector[29+8*DataLength] = 0; CANVector[30+8*DataLength] = 0; CANVector[31+8*DataLength] = 0; CANVector[32+8*DataLength] = 0; CANVector[33+8*DataLength] = 0; //End CRC Section
CANVector[34+8*DataLength] = 1; //CRCDelimiter
CANVector[35+8*DataLength] = 0; //ACKSlot
52 Capítulo 4. Desenvolvimento //EOF CANVector[37+8*DataLength] = 1; CANVector[38+8*DataLength] = 1; CANVector[39+8*DataLength] = 1; CANVector[40+8*DataLength] = 1; CANVector[41+8*DataLength] = 1; CANVector[42+8*DataLength] = 1; CANVector[43+8*DataLength] = 1; //End EOF
CANVector[44+8*DataLength] = 1; //IFS2
CANVector[45+8*DataLength] = 1; //IFS1
CANVector[46+8*DataLength] = 1; //IFS0
p = &CANVector[0];
AssemblyToBus(p, DataLength, I0, I1, Mess0, Mess1, Mess2, Mess3, Mess4, Mess5, Mess6, Mess7); CRC(DataLength, p, 0);
for(i = 0; i <= 46+8*DataLength; i++) {
... //Sending message
4.4. Implementação da unidade de contole ControlUNIT 53
4.4
Implementação da unidade de
con-tole ControlUNIT
A unidade de controle tem por função principal interfacear o controlador CAN com a memória, sendo assim este módulo tem por objetivo controlar os acessos à informação entre os meios. A unidadade de controle recebe os valores da memória e os repassa ao controla-dor CAN, ao mesmo tempo em que faz o sentido oposto, tendo isto em mente, projetamos a unidade de controle “ControlUNIT” com as características presentes na fi-gura 18, enquanto a lógica de funcionamento da mesma pode ser observada na figura 19.
54 Capítulo 4. Desenvolvimento
Figura 18 – Características da unidade de controle Con-trolUNIT.
4.5. Implementação do módulo TLM Target 55
Figura 19 – Máquina de estados da unidade de controle.
4.5
Implementação do módulo TLM
Tar-get
O módulo TLM “Target” tem como função ar-mazenar e disponbilizar os dados vindos tanto do bar-ramento quanto do processador. Nesta implementação o objetivo foi deixá-la o mais simples possível, fazendo com que a complexidade e demais processamentos vi-essem de undades mais robustas, como a unidade de controle “ControlUNIT” e o simulador de processador Initiator. As respectivas características da mesma po-dem ser observadas na figura 20
56 Capítulo 4. Desenvolvimento
“Target”. Uma das características singulares deste bloco é que na prática ele apenas está acessível quando há uma transação TLM em andamento, porém, como o processador é muito mais rápido que a unidade de controle e a latência do barramento, não há problemas de sincronização.
4.6. Implementação da unidade de processamento Initiator 57
Figura 21 – Características da unidade de controle Con-trolUNIT.
4.6
Implementação da unidade de
pro-cessamento Initiator
A unidade de processamento “Initiator” é res-ponsável por simular um pooling que um processador exerceria sobre a memória. Seu papel é basicamente ler periodicamente da memória em busca de dados vindo do barramento e escrever na mesma sempre que necessário enviar uma mensagem. É importante ressaltar que esta unidade, diferentemente das demais, realiza operações apenas em nível TLM. Os pacotes TLM padrão tem tamanho máximo de 4 bytes, como o padrão CAN
pos-58 Capítulo 4. Desenvolvimento
sibilita mensagens de até 8 bytes é necessário que sejam efetuadas duas leituras e duas escritas para se esgotar as possibilidades. As característica da implementação podem ser observadas na figura22.
Figura 22 – Características do simulador de processa-dor Initiator.
59
5 Resultados
Foram realizados dois tipos de testes para a verificação do funcionamento do sistema, um em modo apenas de receptor e outro exlusivamente em modo de transmissor, a fim de poder observar o comportamento do controlador em cada uma das situações.
Foram realizados diversos testes de envio, os ensaios foram elaborados da seguinte maneira:
• Para nível de simulação, foram considerados clocks de um nano segundo.
• O processador realiza diversas escritas e leituras aleatoriamente e com valores aleatórios a cada 50 nano segundos.
• O barramento está sempre desocupado e sempre recebe-se ACK positivo;
• Os bits enviados ao barramento precisam estar estáveis após três ciclos de clock na escrita, para poderem ser lidos no quarto ciclo.
60 Capítulo 5. Resultados
Alguns resultados de simulação podem ser ob-servados na tabela2.
ID Tamanho Dado frame
01 1 0x000000000000000C 61
01 4 0x00000000F000000C 88
01 6 0xCC040000CC0C 105
01 8 0xFF000004FF00000C 128
Tabela 2 – Casos de simulação mostrados, o tamanho dos frames está em bits, enquanto o dos dados está em bytes.
Durante os ensaios, foram observados os instan-tes do término de execução de cada bloco, partindo do momento de escrita na memória, até o momento do último bit estar disponível para amostra no barramento. A tabela 3 apresenta os tempos em que cada módulo terminou seu processo, exceto pelo processador, já que ele inicia com o processo. Seu valor representa o tempo inicial de disposição do dado, sendo assim o cálculo de delay é decrescido de 150.
A tabela 4 mostra os tempos em que as tran-sações são terminadas durante um evento de leitura, muito semelhante à anterior, porém agora não há um offset de tempo, uma vez que o barramento começa a
61
P-M M-U U-C C-B delay*
150 152 156 462 320
150 153 158 592 453
150 155 156 682 543
150 155 156 792 653
Tabela 3 – Latência das transações Processador-Memória, Memória-Unidade de con-trole, Unidade de controle-Controlador, Controlador-Barramento, com o tempo em nano segundos.
B-C C-U U-M M-P delay
305 310 353 405 459
440 446 453 458 508
525 530 587 540 710
630 638 657 692 760
Tabela 4 – Latência das transações Barramentro-Controlador, Controlador-Unidade de controle, Unidade de controle-Memória, Memória-Processador, com o tempo em nano segundos.
63
6 Discussão de resultados
Como previsto nos parâmetros de simulação uti-lizados, a diferença entre as latências dos frames esteve próxima à ordem de grandeza esperada. Os frames correspondentes às mensagens de tamanho oito e seis, possuem uma diferença de 13 bits, como são necessários cinco ciclos de relógio para amostrarmos e processarmos um bit, esperava-se uma diferença de aproximadamente 115 nano segundos de latência.
Observou-se no entando uma diferença de 110 nano segundos, estas pequenas discrepâncias podem ser justificadas devido aos tempos de sincronização e à aleatoriedade dos processos de escrita e leitura realizados pelo processador.
65
7 Conclusão
A implementação de um gateway proporciona a possibilidade de depuração e exploração da arquitetura de maneira mais flexível que o hardware, uma vez que as mudanças podem ocorrer de maneira rápida e modular. Outro aspecto importante é que a interoperabilidade com processadores é um fator muito importante, uma vez que as transações do tipo TLM abstraem a camada física, ao contrário das implementações em SystemC que a modelam muito bem.
Dos objetivos propostos, a implementação tanto do controlador quanto do conversos TLM to CAN foi efetuada com sucesso. Este trabalho descreveu breve-mente as características principais do protocolo CAN e espera ter auxiliado o leitor na compreensão do mesmo.
67
8 Sugestões para trabalhos
futuros
A seguir, são sugeridas algumas adições a serem realizadas em trabalhos futuros com o intuito de melho-rar e testar o gateway em um ambiente mais realista.
• Implementação efetiva do barramento CAN; • Relizar verificação no modo transceptor;
• Utilizar um test bench para a validação do mesmo; • Testar não apenas o controlador, mas sim
utilizá-lo numa rede;
• Modelar a influência de fatores como interferência eletromagnética e checar a robustez a possíveis erros ocasionados pelas mesmas;
• Implementar o protocolo CAN extendido, o que implica em alterar o tamanho do vetor de mensa-gem.
69
Referências
[1] Automotive embedded systems handbook -RICHARD ZURAWSKI, © (2009) by Taylor Francis Group, LLC.
[2] BOSCH, R. "CAN specification version 2.0." Rober Bousch GmbH, Postfach 300240 (1991).
[3] Open SystemC Initiative. "IEEE standard SystemC language reference manual." IEEE Computer Society (2006): 1666-2005.
[4] GHENASSIA, F. Transaction-level modeling with SystemC. Dordrecht, The Netherlands: Springer, (2005).
[5] GAO QIANG, REN DEXUE, ZHANG JIANFENG, WU HAIGIN e SUN JIAN, "The design and implementation of CAN node intelligent communication interface,"2008 Chinese Control and Decision Conference, Yantai, Shandong, (2008), pp. 4954-4956.
[6] TARANI CHAITANYA CHINTA. "Implementation of controller area network and its application", 2007. [7]C. HERBER, D. REINHARDT, A. RITCHTER e A. HERKERSDORF, "HW/SW trade-offs in I/O virtualization for Controller Area Network,"2015 52nd
70 Referências
ACM/EDAC/IEEE Design Automation Conference (DAC), San Francisco, CA, 2015, pp. 1-6.
