Folder Scania Oil 2016 7

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
DEPARTAMENTO DE ELETRÔNICA
BACHARELADO EM ENGENHARIA ELETRÔNICA
CELSO LUIZ MENDES DA SILVA
MODELAGEM E TESTE EM BANCADA DE UMA REDE DE

COMUNICAÇÃO NO PADRÃO SAE J1939
TRABALHO DE CONCLUSÃO DE CURSO
PONTA GROSSA
2018
MODELAGEM E TESTE EM BANCADA DE UMA REDE DE

COMUNICAÇÃO NO PADRÃO SAE J1939
Trabalho de Conclusão de Curso apresen-

tado como requisito parcial à obtenção
do título de Bacharel em Engenharia Ele-
trônica, do Departamento de Eletrônica,
da Universidade Tecnológica Federal do
Paraná.
Orientador: Prof. Dr. Max Mauro Dias

Santos
PONTA GROSSA
2018
Ministério da Educação
Universidade Tecnológica Federal do Paraná
Câmpus Ponta Grossa
Diretoria de Graduação e Educação Profissional
Departamento de Eletrônica
Bacharelado em Engenharia Eletrônica
TERMO DE APROVAÇÃO
MODELAGEM E TESTE EM BANCADA DE UMA REDE DE COMUNICAÇÃO NO

PADRÃO SAE J1939
por
Este Trabalho de Conclusão de Curso foi apresentado às 10:00 de 08 de junho de

2018 como requisito parcial para a obtenção do título de Bacharel em Engenharia
Eletrônica. O candidato foi arguido pela Banca Examinadora composta pelos profes-
sores abaixo citados. Após deliberação, a Banca Examinadora considerou o trabalho
aprovado.
Prof. Dr. Max Mauro Dias Santos

Orientador
Prof. Dr. Frederic Conrad Janzen Prof. Msc. Robson Moreira de Oliveira
Membro Titular Membro Titular
Prof. Dr. Josmar Ivanqui Prof. Msc. Jeferson José Gomes

Responsável pelos TCC Coordenador do Curso
– O Termo de Aprovação assinado encontra-se na Coordenação do Curso –

Dedico este trabalho à minha família, aos
meus amigos, aos meus professores e às
inúmeras pessoas que tornaram o
caminho até aqui possível.
AGRADECIMENTOS
Essa etapa da minha vida só foi possível graças a inúmeras pessoas e institui-
ções. Portanto, é importante expressar meu profundo agradecimento nessas poucas
linhas que seguem.
Agradeço primeiramente e acima de tudo a Deus. A maneira muito singular
como eu encontrei a Deus alguns anos antes de começar a graduação foi decisiva na
minha vida. Sem isso, não teria escolhido os caminhos que escolhi e, portanto, não
teria obtido as vitórias e aprendizados que obtive.
Agradeço à minha família pelo apoio e paciência durante esses longos anos
de graduação. Sem ela, a caminhada até aqui seria impossível. Gostaria de agradecer
em especial aos meus primos Joelson e Vanessa, que desde o começo de tudo são
os meus maiores apoiadores. Também não poderia deixar de agradecer à tia Célia, à
Bruna Langoni, essa flor especial na minha vida, e sua família pelo apoio nessa reta
final.
Agradeço aos meus amigos pelas palavras de incentivo e conforto. Principal-
mente a Bruno e Lara Perondi, tia Jacinta e família. Sem aquela casa de R$ 100,00
por mês (com água e luz inclusos), eu não teria saído de Guarapuava para perseguir
meu sonho de ser engenheiro.
Agradeço aos meus professores e a UTFPR pelo aprendizado. Especialmente
ao meu orientador, Dr. Max Mauro Dias Santos, por sempre me incentivar a fazer o
melhor e me impulsionar a frente. Obrigado Max!
Agradeço ainda a Porsche AG e ao meu ex-chefe Michael Raabe por fazerem
parte da minha graduação de uma maneira tão especial que foi a realização do sonho
de estar junto dos melhores engenheiros do mundo. Obrigado por uma das melhores
partes da minha graduação!
Por fim, não há como colocar aqui nessa página todas as pessoas que mere-
cem reconhecimento. Foram tantas que me ajudaram e impulsionaram até aqui, que
uma folha inteira somente de nomes me parece ser insuficiente. Ficam os meus agra-
decimentos a vários pelas caronas, pelos trocados emprestados/doados, pelas pala-
vras incentivadoras, pelas listas de exercícios, pelos sorvetes compartilhados, etc.
Demore o tempo que for para decidir o
que quer da vida, e depois que decidir não
recue ante a nenhum pretexto, porque o
mundo tentará te dissuadir (Nietzsche,
Friedrich, 1885).
RESUMO
MENDES DA SILVA, Celso Luiz. MODELAGEM E TESTE EM BANCADA DE UMA

REDE DE COMUNICAÇÃO NO PADRÃO SAE J1939. 2018. 66 f. Trabalho de
Conclusão de Curso (Bacharelado em Engenharia Eletrônica) – Universidade
Tecnológica Federal do Paraná. Ponta Grossa, 2018.
A quantidade de componentes eletrônicos tem aumentado em automóveis ao longo

dos anos. Quanto mais sistemas digitais em um veículo, maior a quantidade e a com-
plexidade de dados que devem ser transmitidos entre as unidades de controle ele-
trônico do automóvel e dispositivos externos. Assim, é necessário o uso de redes de
comunicação automotiva para transmitir e gerenciar esses dados gerados. A rede CAN
é uma das redes consagradas na indústria automotiva, porém o processo de desen-
volvimento dessa rede, ainda hoje, é constante. Baseados nas redes CAN, surgem
protocolos que especificam ainda mais elementos da comunicação de dados, como é
o caso do SAE J1939. Por esse motivo, esse trabalho visa mostrar técnicas de desen-
volvimento de uma rede CAN baseadas no protocolo SAE J1939 e mostrar a interação
dessa rede com uma bancada com ECUs reais, sendo isso parte de um processo de
desenvolvimento utilizado nas montadoras de veículos.
Palavras-chave: Redes Automotivas. CAN. SAEJ1939. Modelagem. Teste.

ABSTRACT
MENDES DA SILVA, Celso Luiz. MODELING AND TEST OF A COMMUNICATION

NETWORK OF SAEJ1939 STANDARD IN A WORKBENCH. 2018. 66 p. Final
Coursework (Bachelor’s Degree in Electronic Engineering) – Federal University of
Technology – Paraná. Ponta Grossa, 2018.
The number of electronic devices are increasing in the automobiles over the years. The
more digital systems are part of a vehicle, the more complex data shall be transmitted
between electronic control units of the vehicle themselves and also with external de-
vices. Thus, it is necessary the use of automotive networks to transmit and manage
the generated data from the vehicles. The Controller Area Network (CAN) is one of
the established networks in the automotive industry, however its development process
still remains nowadays. Based on the CAN emerge protocols that specify even more
the data communication elements as the SAE J1939. For this reason, this work aims
to show development techniques for CAN based on the SAE J1939 protocol and also
show the interaction between this network with a workbench made by real ECUs, being
this part of the development process used by the car manufactures.
Keywords: Automotive Networks. CAN. SAEJ1939. Modeling. Test.

LISTA DE ILUSTRAÇÕES
Figura 1 – Mudança nas áreas de desenvolvimento de tecnologia na indústria

automotiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figura 2 – Configuração básica de uma rede de comunicação . . . . . . . . . . 19
Figura 3 – Comunicação de dois dispositivos segundo o padrão ISO/OSI . . . 20
Figura 4 – Redes em funcionamento em um veículo de classe média . . . . . . 22
Figura 5 – Construção física da CAN . . . . . . . . . . . . . . . . . . . . . . . . 23
Figura 6 – Modelo ISO/OSI para uma rede CAN . . . . . . . . . . . . . . . . . 24
Figura 7 – Diferenças de tensão entre os fios que geram bits no High-Speed CAN 25
Figura 8 – Como são gerados os níveis lógicos em uma rede CAN 2.0 . . . . . 26
Figura 9 – Diferenças de tensão entre os fios que geram bits no Low-Speed CAN 26
Figura 10 – Pinagem do conector DB-9 para acesso a rede . . . . . . . . . . . . 26
Figura 11 – Divisão de uma mensagem CAN . . . . . . . . . . . . . . . . . . . . 27
Figura 12 – Frame CAN 2.0A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 13 – Frame CAN 2.0B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 14 – Exemplo de três nós que disputam o barramento . . . . . . . . . . . 30
Figura 15 – Caminho seguido por um sinal desde a aquisição até o escalonamento 30
Figura 16 – Sinal analógico seno que deve passar pelo processo de amostragem 31
Figura 17 – Exemplo de um PGN . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 18 – Tabelas usadas para o desenvolvimento do banco de dados de Hu
et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figura 19 – Desenvolvimento segundo o modelo V . . . . . . . . . . . . . . . . . 37
Figura 20 – Bancada para desenvolvimento de software automotivo de um mo-
delo Golf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 21 – Interface do CANoe . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 22 – Interface VN1610 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figura 23 – Tela inicial do BUSMASTER® . . . . . . . . . . . . . . . . . . . . . . 41
Figura 24 – Kvaser Leaf Light v2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 25 – Etapas do desenvolvimento do trabalho . . . . . . . . . . . . . . . . 43
Figura 26 – Proposta de execução . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 27 – Passos para criação do banco de dados - Parte I . . . . . . . . . . . 46
Figura 28 – Passos para criação do banco de dados - Parte II . . . . . . . . . . 47
Figura 29 – Bloco de Simulink para Injetar Mensagens no Barramento . . . . . . 47
Figura 30 – Mensagem de Velocidade sendo escrita . . . . . . . . . . . . . . . . 47
Figura 31 – Bancada e materias utilizados nos testes . . . . . . . . . . . . . . . 48
Figura 32 – Distribuição dos instrumentos do painel . . . . . . . . . . . . . . . . 48
Figura 33 – Mensagens lidas no barramento antes da associação de um dicio-
nário de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 34 – Mensagens no barramento depois da utilização do dicionário de dados 50
Figura 35 – Sinais lidos no barramento . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 36 – Sinal da posição do pedal aquirido através de uma mensagem CAN 52
Figura 37 – Sinal da posição do pedal adquirido diretamente nos pinos do pedal 52
Figura 38 – Gráficos no Simulink de saída . . . . . . . . . . . . . . . . . . . . . . 52
Figura 39 – Sinal visto pelo osciloscópio com valor igual a 0 . . . . . . . . . . . . 53
Figura 40 – Sinal visto pelo osciloscópio com valor igual a 100 . . . . . . . . . . 53
Figura 41 – Sinais de pedal e velocidade lidos no Busmaster® . . . . . . . . . . 54
Figura 42 – Log com todas as mensagens do barramento CAN . . . . . . . . . . 54
Figura 43 – Observação do Time Stamp da Mensagem VP2_X_V . . . . . . . . 55
Figura 44 – Variação do atraso na entrega da mensagem VP2_X_V . . . . . . . 55
Figura 45 – Zoom de um período com muito jitter da mensagem VP2_X_V . . . 56
Figura 46 – Configuração para testes em trabalhos futuros . . . . . . . . . . . . 58
LISTA DE TABELAS
Tabela 1 – Classes de redes automotivas . . . . . . . . . . . . . . . . . . . . . 22

Tabela 2 – Extensão vs Taxa de Transmissão no Barramento . . . . . . . . . . 24
Tabela 3 – Pinos do conector DB-9 para uma rede CAN . . . . . . . . . . . . . 27
Tabela 4 – Exemplo de um SPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
LISTA DE ABREVIATURAS, SIGLAS E ACRÔNIMOS
ABREVIATURAS
kbps Kilobits por segundo

km/h Quilômetros por hora
m Metros
Mbps Megabits por segundo
rpm Rotações por minuto
V Volts
SIGLAS
ACK Acknowledgement
CAN Controller Area Network
CAN-FD Controller Area Network with Flexible Data-Rate
CRC Cyclic Redundancy Check
DLC Data Length Code
ECU Unidades de Controle Eletrônico, do inglês Electronic Control Units
EOF End of Frame
HIL Hardware-In-The-Loop
ID Identifier
IDE Identifier Extension
IP Instrument Panel
ISO International Organization for Standardization
LIN Local Interconnect Network
MBD Model-based Design
MIL Model-In-The-Loop
OEM Original Equipment Manufacturer
OSI Open Systems Interconnection
PGN Parameter Group Number
PIL Processor-In-The-Loop
RTR Remote Transmission Request
SAE Sociedade dos Engenheiros Automotivos, do inglês Society of Automo-
tive Engineers
SIL Software-In-The-Loop
SOF Start of Frame
SPN Suspect Parameter Number
WCBT Worst-case Blocking Time
WCQD Worst-case Queuing Delay
WCRT Worst-case Response Time
ACRÔNIMOS
A/D Analógico-Digital
CAN_H CAN High
CAN_L CAN Low
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 TEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 OBJETIVOS GERAIS . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 OBJETIVOS ESPECÍFICOS . . . . . . . . . . . . . . . . . . . . . . 16
1.5 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7 ORGANIZAÇÃO DO TRABALHO . . . . . . . . . . . . . . . . . . . 18
2 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 REDES DE COMUNICAÇÃO . . . . . . . . . . . . . . . . . . . . . 19
2.2 REDES AUTOMOTIVAS . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 O CONTROLLER AREA NETWORK (CAN) . . . . . . . . . . . . . . 23
2.3.1 Camada Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.2 Camada de Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2.1 Frame CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2.2 Arbitragem de mensagens . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.2.3 Requisitos temporais de uma rede CAN . . . . . . . . . . . . . . . . 29
2.4 SAE J1939 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5 D ESENVOLVIMENTO DE UM Database . . . . . . . . . . . . . . . . . . 35
2.6 D ESENVOLVIMENTO DE UMA REDE CAN . . . . . . . . . . . . . . . . 35
2.6.1 Desenvolvimento clássico . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6.2 Desenvolvimento baseado em modelos . . . . . . . . . . . . . . . . . 37
2.7 LEITURA DE DADOS NA REDE CAN: FERRAMENTAS MAIS
UTILIZADAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.7.1 CANoe e família Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.7.2 BUSMASTER® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.7.3 KVASER Leaf Light v2 . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.8 A RQUITETURA DE ECU S NO CAMINHÃO VOLVO FH . . . . . . . . . . 41
3 MATERIAIS E MÉTODOS . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1 D ELIMITAÇÃO DO TEMA . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 P ESQUISA BIBLIOGRÁFICA . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 L EVANTAMENTO DE HIPÓTESES . . . . . . . . . . . . . . . . . . . . . 45
3.4 D ESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.1 Criação do banco de dados . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.2 Simulação CAN através do Matlab/Simulink . . . . . . . . . . . . . . 46
3.5 T ESTES E AQUISIÇÃO DE DADOS . . . . . . . . . . . . . . . . . . . . . 48
3.6 E SCRITA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4 RESULTADOS E DISCUSSÃO . . . . . . . . . . . . . . . . . . . . . 50
5 CONCLUSÕES E PERSPECTIVAS . . . . . . . . . . . . . . . . . . . 57
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
APÊNDICES 64
APÊNDICE A – LINHA DE CÓDIGO PARA A ANÁLISE DOS SINAIS 65
14
1 INTRODUÇÃO
A indústria automotiva está em constante desenvolvimento e as exigências

dos clientes em relação as questões referentes ao desempenho, conforto e meio am-
biente tem aumentado. Segundo Mohr et al (MOHR et al., 2013), as companhias do
setor têm atualmente quatro grandes desafios para serem superados, que são: com-
plexidade e custos, mercados divergentes, demanda digital e mudança do panorama
da indústria. Em especial, a demanda digital está altamente relacionada com a tec-
nologia embarcada nos veículos, uma vez que questões como conectividade, active
safety e assistência ao motorista aparecem em foco.
Bäker (BAEKER, 2014) afirma ainda que nos últimos 20 anos a inovação na
indústria automotiva têm se desenvolvido com foco nos produtos eletrônicos, princi-
palmente nas classes mais luxuosas de automóveis. O gráfico da figura 1 foi adaptado
de uma projeção feita pela empresa Mercer Management Consulting que na época
já previa a crescente importância da eletrônica embarcada na indústria automotiva. É
possível perceber no gráfico que componentes eletrônicos se tornam parte cada vez
maior da composição de um automóvel.
Figura 1 – Mudança nas áreas de desenvolvimento de tecnologia na indústria

automotiva
Fonte: Adaptado de (MERCER MANAGEMENT CONSULTING; FRAUNHOFER

GESELLSCHAFT, 2003).
15
Com o aumento da eletrônica embarcada em veículos, têm-se imediatamente

o aumento da quantidade e da complexidade de dados que as Unidades de Con-
trole Eletrônico, do inglês Electronic Control Units (ECU), devem processar e trans-
mitir. Basicamente, uma ECU é um módulo eletrônico que controla dados de sen-
sores, atuadores, outras ECUs e dos ocupantes de um veículo. A melhor estratégia
para fazer comunicação dos dados que as diferentes ECUs geram é a utilização de
uma rede de dados com um protocolo estabelecido. Na indústria automotiva os pro-
tocolos de comunicação comumente utilizados são: Controller Area Network (CAN)
(ISO11898/TC22/SC31, 2015), Local Interconnect Network (LIN) (SAE, 2005a), Flex-
Ray (ISO17458, 2010) e o Automotive Ethernet (ISO/TC22/SC31, 2010).
Dentre esses, o protocolo CAN ganhou popularidade desde os anos 80,
sendo até hoje o protocolo mais utilizado na indústria automotiva (NAVET et al.,
2005). Ele é um protocolo serial, não-determinístico, não-preemptivo, desenvolvido
nos anos 80 pela Bosch GmbH (ROBERT BOSCH GMBH, 1991) e padronizado
pelas normas da International Organization for Standardization (ISO) (ISO 11898)
(ISO11898/TC22/SC31, 2015) e Sociedade dos Engenheiros Automotivos, do inglês
Society of Automotive Engineers (SAE) (SAE, 2005b). Sua primeira utilização em veí-
culos de série foi feita pela Mercedes Benz na Alemanha (BAEKER, 2014) e desde
então a rede CAN é bastante utilizada por montadoras de veículos, uma vez que a
rede é simples de ser implementada, de baixo custo, identifica e corrige erros e é
segura para aplicações de tempo real.
Apesar de não ser uma tecnologia nova, a rede CAN ainda é aplicada na co-
municação automotiva e por esse fato está em constante melhoria, como nas pesqui-
sas feitas por Bernardeschi (BERNARDESCHI et al., 2017), Bordoloi & Samii (BOR-
DOLOI; SAMII, 2014), Di Natale et al (NATALE; SILVA; SANTOS, 2016) e Urul (URUL,
2015) devido ao desenvolvimento do Controller Area Network with Flexible Data-Rate
(CAN-FD) (ROBERT BOSCH GMBH, 2012). Elas visam aumentar a velocidade da
rede e o volume de dados transmitidos por ela e a melhorar as questões de segu-
rança contra ataques externos de terceiros. Nesse sentido, esse trabalho mostra como
acontece hoje em dia o desenvolvimento de uma rede baseada no protocolo CAN na
indústria automotiva.
16
1.1 TEMA
Redes de comunicação automotiva são importantes para o desenvolvimento

do setor, sem elas o peso e os gastos seriam muito maiores para a produção de
veículos. Entretanto, é necessário se investigar a implementação e a eficiência das
redes de comunicação.
Este documento visa mostrar um estudo de caso sobre o desenvolvimento
de uma rede automotiva no padrão SAE J1939 utilizando os softwares comerciais
Busmaster® e Matlab/Simulink® e mostrar o impacto dos requisitos temporais da rede
nos dados lidos. Para se demonstrar o desenvolvimento completo das mensagens no
protocolo CAN, uma bancada com duas ECUs, um tacógrafo e um Instrument Panel
(IP) do caminhão modelo FH12 da Volvo serão utilizados.
1.2 PROBLEMA
A implementação de uma rede de comunicação, apesar de parecer trivial, é

complexa e deve ser feita de tal maneira que o processo tenha o número de erros ten-
dendo a zero por questões de segurança. Sistemas de comunicação automotiva onde
há um atraso muito grande na entrega de mensagens, por exemplo, são passíveis de
erro e isso se torna perigoso quando há funções que tomam decisões baseadas na
informação recebida.
1.3 OBJETIVOS GERAIS
Mostrar o processo de desenvolvimento de redes de comunicação automotiva

desde a criação do Database das mensagens até a comunicação entre ECUs. Além
disso, mostrar a importância dos requisitos temporais da rede.
1.4 OBJETIVOS ESPECÍFICOS
Os principais objetivos a serem atingidos até o final do presente trabalho são:
• Entender o processo e a importância da criação de um Database padronizado.
• Desenvolver um Database e Setups de testes rápidos para desenvolvimento de

17
uma rede CAN.
• Mostrar o desempenho da rede com as mensagens criadas.
• Elucidar o desenvolvimento com algumas das principais ferramentas disponíveis

no mercado para redes de comunicação automotiva.
1.5 JUSTIFICATIVA
Devido a importância do tema "redes automotivas" e principalmente da grande

utilização do protocolo CAN, este trabalho visa mostrar como acontece o desenvolvi-
mento das mensagens da rede CAN, desde as primeiras fases até a aplicação. Caso
exista muito atraso na entrega de mensagem isso pode se tornar um problema.
A realização desse trabalho justifica-se pela investigação dos efeitos do nú-
mero de mensagens CAN em um barramento.
1.6 METODOLOGIA
Para este trabalho foi realizada uma ampla pesquisa bibliográfica em reposi-
tórios acadêmicos e científicos. Uma vez que as principais fontes foram estudadas, o
próximo passo foi interpretar as normas técnicas do documento SAE J1939-71 SAE
(2005b) e comparar com os dados lidos no computador através da interface KVASER®
e o software BUSMASTER®. Dessa maneira, observando-se o comportamento das
mensagens conforme o estímulo dado na entrada, que foi possível criar o Database
das ECUs disponíveis no laboratório.
Depois disso, usou-se o arquivo ".dbf" produzido no BUSMASTER® em um
projeto de rede CAN em ambiente Simulink® para injetar mensagens no barramento.
Numa terceira etapa as mensagens da rede foram adquiridas através do KVA-
SER® pelo BUSMASTER® e fez-se a análise dos sinais criados e dos requisitos tem-
porais da rede. Maiores detalhes sobre a metodologia utilizada estão descritos no
capítulo 3.
18
1.7 ORGANIZAÇÃO DO TRABALHO
Este trabalho foi organizado de maneira a apresentar o conteúdo de forma

pragmática para proporcionar ao leitor uma leitura lógica e agradável. Os capítulos
estão aqui descritos de forma breve, como segue abaixo.
Capítulo 2: neste capítulo é feita uma revisão bibliográfica com técnicas do
estado da arte. Os conceitos de redes de comunicação, redes de comunicação em
automóveis, rede CAN e padrão SAE J1939 são descritos. Além disso, serão apre-
sentados alguns equipamentos que facilitam o trabalho do engenheiro que precisa
acessar e manipular as informações transmitidas pelas redes de comunicação de um
carro.
Capítulo 3: no capítulo 3 está descrita a metodologia abordada para a reali-
zação desse trabalho. Ainda apresenta-se os materiais necessários para a realização
da pesquisa.
Capítulo 4: nessa seção serão apresentados os resultados obtidos de um es-
tudo de caso através da utilização de bancada de testes com duas ECUs, um tacógrafo
e um painel de instrumentos do caminhão modelo FH12 da Volvo.
Capítulo 5: aqui estão as considerações finais sobre o trabalho, bem como
as conclusões obtidas pela utilização do método estudado. Ainda neste capítulo,
apresenta-se sugestões de trabalhos futuros no tema.
19
2 REVISÃO DA LITERATURA
Esse capítulo é destinado a uma breve revisão dos conceitos de redes de

comunicação, a elucidação da importância das redes no setor automotivo e, princi-
palmente, a descrever o formato de uma rede CAN e as ferramentas utilizadas no
processo de desenvolvimento dela.
2.1 REDES DE COMUNICAÇÃO
Uma rede de comunicação existe quando dois ou mais dispositivos estão co-
nectados por links de comunicação (FOROUZAN, 2008). Para que a comunicação
aconteça entre esses dispositivos é necessário que haja a ligação física e o protocolo
de comunicação (software), caso contrário, afirma Forouzan (FOROUZAN, 2008), será
como que duas pessoas que falam línguas diferentes tentassem se comunicar.
Pode-se dizer que uma rede é formada basicamente de dois componentes
essenciais: hardware e software. Na figura 2 está demonstrada a configuração mí-
nima de uma rede para que haja troca de informação entre dois dispositivos. Na figura
observa-se que há dois dispositivos comunicantes que podem ser dispositivos micro-
controlados, por exemplo. Esses dispositivos compartilham de um meio que pode ser
um fio elétrico, um cabo óptico ou o ar. Para que haja a comunicação é necessário
que os dispositivos tenha um protocolo em comum, essa é a parte de software. Um
elemento muito importante da comunicação é a mensagem. Para que haja comuni-
cação é necessário que um dos dispositivos, denominado emissor, deseje transmitir
uma mensagem ao outro dispositivo, denominado receptor.
Figura 2 – Configuração básica de uma rede de comunicação
Fonte: Adaptado de (FOROUZAN, 2008)
Como mencionado acima, para que se transmita dados entre dispositivos é

20
necessário que se estabeleçam regras de comunicação, assim surgem os padrões.

Atualmente, os padrões mais utilizados são o Open Systems Interconnection (OSI) e
o Internet. O modelo ISO/OSI, que é o padrão em que o CAN utiliza, é composto de
sete camadas de comunicação, que são: Física, Enlace de Dados, Rede, Transporte,
Sessão, Apresentação e Aplicação (SOUSA, 2002). A figura 3 mostra como acontece
a comunicação entre dois dispositivos pelo modelo ISO/OSI.
Figura 3 – Comunicação de dois dispositivos segundo o padrão

ISO/OSI
Fonte: (SOUSA, 2002)
Cada camada do modelo tem uma função que permite com que aconteça a
comunicação. A seguir, descreve-se de maneira sucinta as funções de cada camada
do modelo ISO/OSI:
Camada de aplicação
Camada mais alta do modelo. Segundo Silva (SILVA, 2015), é nessa camada
que o usuário pode interagir com a rede requisitando serviços. O usuário pode ser
humano ou software.
Camada de apresentação
Essa camada é que faz a transdução entre as requisições feitas na camada
da aplicação e a rede em si. Basicamente, ela transforma uma informação obtida do
usuário em um dado que será entendido pela rede. Nessa fase as informações como
letras, números e símbolos serão convertidas em bits. Na camada de apresentação
21
ainda é possível fazer criptografia e compressão de dados, conforme a necessidade

do projeto.
Camada de sessão
Segundo Forouzan (FOROUZAN, 2008), nessa camada a comunicação entre
sistemas é estabelecida, mantida e sincronizada. As principais funções dessa camada
são o controle de diálogo e a sincronização entre dispositivos comunicantes.
Camada de transporte
Essa camada garante que haverá entrega da mensagem da origem ao des-
tino. É aqui também onde é feito parte do controle de erros de transmissão, o controle
de fluxo, o controle de conexão, a segmentação e a reconstrução da mensagem.
Camada de rede
A camada de rede é responsável pela entrega das mensagens. As princi-
pais atividades dessa camada são: endereçamento lógico e roteamento (FOROUZAN,
2008).
Camada de enlace de dados
É onde ocorre o escalonamento de dados no formato do protocolo que irá
transmitir a mensagem. Assim como na camada de transporte, é possível aqui detectar
possíveis erros de transmissão. Também recebe o nome de camada de ligação e data
link.
Camada física
Onde estão definidas todas as especificações do meio físico onde ocorrerá a
transmissão de dados. Aqui define-se tensão, tempo de transmissão, cabos, conecto-
res, topologia, etc.
2.2 REDES AUTOMOTIVAS
No setor automotivo o uso de redes de comunicação traz algumas vantagens

claras como: diminuição de peso e espaço ocupados por fios e, por consequência,
redução de custos no produto final, como observado por Navet et al. (NAVET et al.,
2005).
A princípio, as redes automotivas surgiram para comunicar as diversas ECUs
presentes nos veículos, porém com o avanço da tecnologia, elas começaram a ser em-
pregadas cada vez mais em funções próximas do usuário humano, como por exemplo
22
em aplicações de Infotainment. Devido essa grande diversidade na utilização das re-

des, elas são classificadas atualmente pela SAE (SILVA, 2015). A tabela 1 adaptada
de Liu et al. (LIU; AN; YANG, n.d.) mostra a atual divisão de classes das redes auto-
motivas. O CAN está inserido nas classes B e C.
Tabela 1 – Classes de redes automotivas
Classe Velocidade Aplicação
A < 10 kbps Funções não críticas. Por exemplo áudio
B 10 kbps a 125 kbps Sensores, atuadores, painel, etc
C > 125 kbps Dados de tempo real
Fonte: (LIU; AN; YANG, n.d.)
Geralmente, automóveis apresentam mais de uma rede em funcionamento e

a utilização destas se dá conforme a aplicação que se necessita. A figura 4 ilustra
parte das redes que funcionam em um automóvel de classe média. Na figura é pos-
sível observar que em um automóvel de classe média podem funcionar, ao mesmo
tempo, uma rede High-Speed CAN, uma Low-Speed CAN, uma LIN, uma MOST e
que todas elas se comunicam internamente e externamente através de gateways. O
painel somente recebe as informações das redes CAN.
Figura 4 – Redes em funcionamento em um veículo de classe média
Fonte: Adaptado de (ZIMMERMAN; SCHMIDGALL, 2006)

23
2.3 O CONTROLLER AREA NETWORK (CAN)
O CAN é um protocolo de comunicação serial que surgiu para ser simples, se-
guro e com bom custo-benefício (BAEKER, 2014). Ele suporta eficientemente controle
de tempo real com um alto grau de confiabilidade (ROBERT BOSCH GMBH, 1991).
Essa característica é de extrema importância quando se desenvolve produtos que de-
vem conter o menor número possível de erro nos seus processos, como é o caso de
veículos automotores.
A construção da rede com n-ECUs é simples e acontece como representado
na figura 5. Os dispositivos comunicantes ficam conectados a um barramento e este
possui terminadores de rede nas pontas, a fim de evitar o espelhamento de sinal.
A conexão geralmente é feita por um par de fios trançados, podendo ser blindados
ou não (a especificação dependerá das exigências do projeto). Cada dispositivo que
compartilha o barramento recebe o nome de nó e cada nó da rede será responsável
por transmitir e receber um número determinado de mensagens.
Figura 5 – Construção física da CAN
Fonte: Autoria própria
A velocidade de transmissão de dados varia conforme a extensão do barra-

mento. Para o CAN clássico, a velocidade máxima atingida em 40 metros de fio é de
1 Megabits por segundo (Mbps). A tabela 2 mostra a relação típica Extensão do Fio x
Taxa de Transmissão no Barramento.
O documento da Robert Bosch GmbH (ROBERT BOSCH GMBH, 1991) de-
fine dois modelos de CAN. Um de baixa velocidade, específicado na ISO 11898/3,
que recebe o nome de Low-Speed CAN, e um de alta velocidade, especificado na
24
ISO 11898/2, que recebe o nome de High-Speed CAN. Além disso, existe a subdivi-
são do High-Speed CAN em CAN 2.0A e CAN 2.0B, onde o primeiro diz respeito às
mensagens com identificador de 11 bits e o segundo às mensagens com identificador
estendido de 29 bits. O segundo foi desenvolvido para aplicações onde há um maior
número de mensagens na rede.
Tabela 2 – Extensão vs Taxa de Transmissão no Barramento
Extensão do Fio(m) Taxa de Transmissão no Barramento (Mbps)
40 1,00
100 0,50
200 0,25
500 0,10
1000 0,05
Fonte: (CORRIGAN, 2008)
Com relação ao modelo OSI, o CAN utiliza, por padrão, duas camadas: a
camada física e a camada de enlace. As demais camadas podem ser utilizadas pelos
projetistas de rede, porém não são necessárias para o funcionamento da rede (SILVA,
2015). A figura 6 mostra como pode ser projetada uma rede CAN com base no modelo
OSI. Segundo Corrigan (CORRIGAN, 2008), ela mostra que as funções da camada
de aplicação podem ser implementadas por um desenvolvedor de software ou por um
protocolo de alto nível, como por exemplo o CANopen, o DeviceNet e o SAEJ1939.
Figura 6 – Modelo ISO/OSI para uma rede CAN
Fonte: Adaptado de (CORRIGAN, 2008)
As divisões do protocolo conforme o modelo OSI estão elucidados nas subse-

ções que seguem.
2.3.1 Camada Física
Como descrito anteriormente, na camada física de uma rede é onde são de-
finidas as especificações mecânicas e elétricas, bem como procedimentos e funções
25
que os dispositivos desempenham para possibilitar a transmissão de dados.

Na rede CAN a transmissão acontece em um barramento com par de fios
trançados que podem ser blindados ou não. Essa configuração é feita para que os
níveis lógicos sejam obtidos através da diferença de tensão entre os condutores. Os
fios recebem o nome de CAN High (CAN_H) e CAN Low (CAN_L).
Para o High-Speed CAN 2.0, os níveis de tensão que geram bits na rede estão
apresentados na figura 7. Essa diferença entre níveis, gera tensões de 0 Volts (V) ou
2V, essa diferença será interpretada pelo controlador como um bit 0 ou 1 (0V é lido
como um bit 1 e 2V é lido como um bit 0). No protocolo CAN o bit 1 é recessivo e o bit
0 é dominante. Essa diferença lógica está mostrada na figura 8, onde nota-se que os
fio CAN_H e CAN_L quando conduzem 2,5 V cada, geram uma diferença de potêncial
entre os dois fios de 0 V. Essa diferença é entendida no controlador CAN como um bit
1, que é recessivo. Por outro lado, quando CAN_H está em 3,5 V e CAN_L está em
1,5 V a diferença de potêncial entre os fios é de 2 V, o que é entendido no controlador
CAN como um bit 0, que é dominante no protocolo.ele
Figura 7 – Diferenças de tensão entre os fios que geram bits no

High-Speed CAN
Fonte: (GUIMARãES, 2007)
No Low-Speed CAN a diferença de tensão é dada como na figura 9. Observa-

se aqui que ao contrário do High-Speed CAN, um bit recessivo não é produzido por
uma diferença de potêncial igual a 0. O bit 1, recessivo, acontece quando a diferença
de potêncial entre CAN_H e CAN_L é igual a 5 V, enquanto que uma diferença de 2,2
V produzirá um bit 0, dominante. A forma de obtenção de bits 0s e 1s é semelhante
ao procedimento na figura 8.
Para acesso externo do barramento, a norma prevê que as interfaces de
acesso à rede usem um conector DB-9 . A pinagem do conector está definida como
na figura 10.
26
Figura 8 – Como são gerados os níveis lógicos em uma rede CAN

2.0
Fonte: (BAEKER, 2014)
Figura 9 – Diferenças de tensão entre os fios que geram bits no

Low-Speed CAN
Fonte: Adaptado de (VECTOR, 2010)
Figura 10 – Pinagem do conector DB-9 para acesso a rede
Os pinos e as saídas relacionados em uma tabela ficam como mostrado na

tabela 3. Os pinos 2 e 7 são os condutores onde acontece a comunicação CAN através
do CAN_L e CAN_H, respectivamente. A tabela torna mais fácil o entendimento da
pinagem do conector DB-9.
27
Tabela 3 – Pinos do conector DB-9 para uma rede CAN

Pino 1 Reservado
Pino 2 CAN_L
Pino 3 Terra
Pino 4 Reservado
Pino 5 Reservado
Pino 6 0V (terra)
Pino 7 CAN_H
Pino 8 Reservado
Pino 9 +V (alimentação opcional)
Fonte: Autoria Própria
2.3.2 Camada de Enlace
Na camada de enlace é onde acontece o escalonamento de sinais, o desen-

capsulamento de sinais, a arbitragem de IDs, a detecção e a correção de erros. Essa
camada é muito importante para o protocolo, pois é devido as funções dela que ele se
torna confiável para utilização em aplicações de tempo real.
2.3.2.1 Frame CAN
Um frame CAN está dividido em três campos na camada de enlace, são eles:
o campo de identificação ou Header, o campo de dados úteis ou de Payload e o
campo de reconhecimento ou Trailer. A figura 11 mostra a função de cada um desses
campos.
Figura 11 – Divisão de uma mensagem CAN
Cada parte desses campos ainda é subdividida em outros campos, como mos-
trado na figura 12.
As subdivisões da figura 12 explicados unitariamente são:
• Bus idle: tempo em que o barramento fica livre para poder transmitir. Aparece
antes do começo e depois do final de cada frame.
28
Figura 12 – Frame CAN 2.0A
Fonte: Adaptado de (VECTOR, 2010)
• Start of Frame (SOF): bit dominante que indica o início de transmissão de um

nó. Todo nó quando deseja iniciar a transmissão, manda um SOF avisando que
irá começar a transmitir.
• Identifier (ID): onde o identificador de cada mensagem é enviado. Em uma situa-

ção onde várias mensagens pedem permissão para transmitir ao mesmo tempo,
a mensagem que tiver o ID com o maior número de bits dominantes irá ganhar o
barramento.
• Remote Transmission Request (RTR): quando um nó precisa transmitir remo-

tamente, esse bit é enviado dominante. Em aplicações automotivas esse bit é
sempre transmitido recessivo.
• Identifier Extension (IDE): indica se o frame transmitido é 2.0A ou 2.0B.
• O bit r é reservado no protocolo para aplicações futuras.
• Data Length Code (DLC): indica o tamanho do payload da mensagem. No pro-

tocolo CAN2.0 esse tamanho vai de 0 à 8 Bytes.
• Data Field: onde os dados úteis são transmitidos.
• Cyclic Redundancy Check (CRC): campo de checagem de erros. O CRC é um

número produzido por um polinômio e varia conforme a mensagem enviada.
Esse número é enviado pelo emissor e conferido pelo receptor. Caso o número
que o receptor leia não seja aquele esperado, o receptor envia então um sinal
de erro no barramento e pede retransmissão ao emissor.
• Logo após o CRC está o delimitador de CRC. Que indica que a contagem do
polinômio está terminada.
• Acknowledgement (ACK): indica que a mensagem foi transmitida com sucesso.

29
• Existe também um delimitador do campo de reconhecimento que indica que o

reconhecimento da mensagem foi completado com sucesso.
• End of Frame (EOF): onde são transmitidos sete bits recessivos avisando ao
receptor que o envio da mensagem acabou.
No CAN 2.0B o frame ainda recebe um ID extendido com mais 18 bits logo
após o campo IDE, como mostrado na figura 13. Desta maneira é possível utilizar um
maior número de mensagens e nós em uma rede.
Figura 13 – Frame CAN 2.0B
Fonte: Adaptado de (NASSIN, 2016)
Outro mecanismo de reconhecimento de erros no protocolo CAN é o bit stuf-

fing. A norma ISO 11898 determina que um nó só poderá transmitir cinco bits re-
petidos, incluindo o stuff bit. Por exemplo, se uma mensagem contém a informação
111111011000000, elá deverá então receber a cada cinco bits iguais, um bit invertido,
assim essa informação passará a ser 11111010110000010.
2.3.2.2 Arbitragem de mensagens
A arbitragem no CAN acontece a nível de bit, onde um bit 0 é dominante e

tem prioridade sobre um bit 1, que é chamado recessivo. Isso acontece para que as
mensagens com o maior número de zeros no campo de identificação tenham maior
prioridade e sejam transmitidas antes das mensagens com menor prioridade. A figura
14 mostra um exemplo de três nós que desejam iniciar uma transmissão no barra-
mento. O nó que possui o maior número de zeros no campo de identificação ganha o
barramento e pode transmitir.
2.3.2.3 Requisitos temporais de uma rede CAN
Mesmo em um sistema de tempo real crítico (hard real-time system) existe um

atraso, ainda que mínimo, entre o acontecimento do evento medido e a transmissão
dele em uma mensagem de rede. Maior parte desse delay acontece por causa de
30
Figura 14 – Exemplo de três nós que disputam o barramento
Fonte: Adaptado de (SANTOS, 2014)
dois importantes processos: a conversão Analógico-Digital (A/D) e o escalonamento

de sinais em mensagens. A figura 15 mostra os passos que acontecem desde a leitura
de um sinal até o encapsulamento deste dentro de uma mensagem.
Figura 15 – Caminho seguido por um sinal desde a aquisição até o
escalonamento
Na figura 15 observa-se que transdutor está constantemente medindo a gran-

deza física. Ele converte o estado físico em um sinal elétrico analógico. Esse sinal
elétrico analógico precisa ser convertido depois em um sinal digital, pois é a maneira
que a ECU irá entender a informação e armazená-la. Nesse processo de conversão
fica inserido o primeiro delay do processo. Segundo Arkesteijn et al. (ARKESTEIJN;
KLUMPERINK; NAUTA, 2006) existe um erro a ser considerado no processo de amos-
tragem causado por um jitter na mensagem. Jitter é a variação do atraso de um sinal.
Em um sinal seno, como o da figura 16, que deve passar pelo processo de amostra-
gem, o jitter, que é natural do processo, torna a equação 1 na equação 2. Ou seja, fica
inserido no processo um atraso.
𝑠𝜏,𝑖𝑑𝑒𝑎𝑙 (𝑘) = 𝑠(𝑘𝜏 ) (1)
𝜕𝑠(𝑡)
𝑠𝜏 (𝑘) = 𝑠(𝑘𝜏 + ∆𝑡(𝑘𝜏 )) ≈ 𝑠(𝑘𝜏 ) + ∆𝑡(𝑘𝜏 ). (2)
𝜕𝑡
31
Figura 16 – Sinal analógico seno que deve passar pelo processo de

amostragem
Fonte: (ARKESTEIJN; KLUMPERINK; NAUTA, 2006)
Onde s(t) é o sinal de entrada, 1/𝜏 é a taxa de amostragem, s(k𝜏 ) é o sinal

amostrado e ∆t é o jitter de amostragem.
Entretanto, o atraso total da entrega da mensagem deve conter componentes
de jitter da amostragem tanto quanto do tempo de encapsulamento, de tal maneira que
o jitter total que influência o atraso total de entrega da mensagem é como mostrado
na equação 3.
𝐽𝑡𝑜𝑡𝑎𝑙 = 𝐽𝑎𝑚𝑜𝑠𝑡𝑟𝑎𝑔𝑒𝑚 + 𝐽𝑒𝑠𝑐𝑎𝑙𝑜𝑛𝑎𝑚𝑒𝑛𝑡𝑜 (3)
O atraso de escalonamento de sinais em mensagens é dado como segue. O

escalonamento de sinais em mensagens no CAN nada mais é do que pegar sinais
digitalizados e colocá-los em frames CAN para que possam ser transmitidos. Cada
sinal é mapeado dentro de uma mensagem CAN.
A rede CAN é de transmissão não-determinística, o que quer dizer que os
frames CAN não trafegam de forma periódica. Para que um frame transmita são ne-
cessários alguns passos, como:
1. Esperar que o algoritmo de escalonamento de sinais preencha um frame;
2. Entrar em uma fila de espera no controlador CAN, ou seja entrar em buffer ;
3. Se houver uma mensagem de menor prioridade que começa a transmissão antes

da entrada da mensagem em buffer, então esperar até que a mensagem de
menor prioridade termine a transmissão;
4. Aguardar até que todas as mensagens em buffer com maior prioridade comple-
tem transmissão.
32
Conclui-se então que uma rede CAN não garante que fará transmissão de
maneira síncrona e que ela só consegue garantir que uma mensagem será entre-
gue pelo menos no pior cenário possível: o Worst-case Response Time (WCRT). A
equação 4 mostra como é constituído o WCRT de um frame CAN. Ele é a soma da
variação de atrasos do enfileiramento da mensagem no buffer, ou jitter do buffer (𝐽𝑚 )
com o Worst-case Queuing Delay (WCQD) (𝑤𝑚 ) e o maior tempo de transmissão dela
mesma (𝐶𝑚 ).
𝑅𝑚 = 𝐽𝑚 + 𝑤𝑚 + 𝐶𝑚 (4)
O WCQD de uma mensagem é o maior tempo entre o instante que ela chega
no buffer e o início de transmissão. O valor desse parâmetro é dedo pela equação 5.
∑︁ ⌈︂ 𝑤𝑚 + 𝐽𝑗 + 𝜏𝑏𝑖𝑡 ⌉︂
𝑤𝑚 = 𝐵𝑚 + .𝐶𝑗 (5)
∀𝑗∈ℎ𝑝
𝑇𝑗
(𝑚)
Onde 𝐵𝑚 é o Worst-case Blocking Time (WCBT) dado pela equação 6. Ela

representa o tempo que a mensagem vai ter que esperar até que uma mensagem de
menor prioridade termine a transmissão. 𝜏 é o tempo de transmissão de um único bit.
𝐵𝑚 = max (𝐶𝑘 ) (6)

∀𝑗∈𝑙𝑝(𝑚)
𝐶𝑚 é o maior tempo que uma mensagem leva para transmitir a si mesma. 𝐶𝑚

é dado pela equação 7.
(︂⌊︂ ⌋︂ )︂
34 + 8𝑆𝑚
𝐶𝑚 = + 47 + 8𝑆𝑚 ) 𝜏𝑏𝑖𝑡 (7)
5
Em Tindell & Wellings (TINDELL; HANSSON; WELLINGS, n.d.) e em Davis et
al. (DAVIS et al., 2007) toda essa análise temporal foi levada em conta. Em ambos os
trabalhos, os autores comparam o escalonamento de sinais ao bin packing problem.
Eles comparam os sinais da rede aos bins que devem ser encapsulados em taks
dentro de um processador. As mensagens CAN são comparadas às tasks.
Conclui-se então, que o atraso desde a produção de um sinal até a transmis-
são à uma ECU é a soma do atraso de amostragem com o atraso de escalonamento.
33
2.4 SAE J1939
O SAE J1939 é um protocolo baseado no CAN 2.0B, que especifica, além das
camadas física e de enlace, a camada de aplicação. Esse protocolo é utilizado prin-
cipalmente em veículos pesados de transporte e máquinas rurais, como afirmado por
Junger (JUNGER, 2010). O campo de identificação de mensagem do SAE J1939 é
composto do Parameter Group Number (PGN), endereço da ECU emissora e a prio-
ridade do frame enviado (SILVA, 2015). As principais características desse protocolo
segundo Junger (JUNGER, 2010) são:
• Identificador CAN estendido (29 bits);
• Taxa de transmissão de 250 Kilobits por segundo (kbps);
• Comunicação ponto-a-ponto e broadcast;
• Protocolos de transporte de até 1785 bytes de dados;
• Gerenciamento de rede;
• Definição de grupos de parâmetros para veículos comerciais e outros;
• Grupos de parâmetros específicos de cada Original Equipment Manufacturer

(OEM);
• Diagnóstico.
O SAE J1939 é constituído de uma série de 11 documentos que especificam

diferentes regras para a sua utilização. Isso é feito a fim de padronizar as ligações
entre ECUs. Os cinco principais documentos que constituem o SAE J1939 são:
• J1939/1X - Camada física;
• J1939/21 - Camada de enlace;
• J1939/31 - Camada de rede;
• J1939/71 - Camada de aplicação;
• J1939/81 - Gerenciamento de rede.

34
No SAE J1939/71, onde se específica a camada de aplicação, cada sinal re-

cebe um Suspect Parameter Number (SPN), enquanto que as mensagens recebem
um PGN. Um PGN pode conter vários SPNs. Ou seja, uma mensagem pode carregar
vários sinais, conforme a capacidade de escalonamento da mensagem. Como exem-
plo apresenta-se na tabela 4 um sinal contido na norma e na figura 17, uma mensagem
que pode carregar diversos sinais. Ambos foram escolhidos aleatoriamente na norma.
Tabela 4 – Exemplo de um SPN

SPN 916 Engine Speed 2
Velocidade do motor medida pelo sensor 2
Tamanho do sinal: 2 bytes

Resolução: 0,5 rpm/bit, 0 offset
Largura de dados: 0 a 32, 127,5 rpm
Tipo: Medido
Informação adicional
PGN: 61473
Fonte: Adaptado de (SAE, 2005b)
Figura 17 – Exemplo de um PGN
Fonte: (SAE, 2005b)
É possível observar na figura 17 que o PGN recebe um PDU Format, um

PDU Specific, um Data Page e um Extended Data Page. O PDU Format define se a
mensagem é transmitida em modo ponto-a-ponto ou broadcast (PDU Format > 240,
então transmissão broadcast). O PDU Specific define o endereço do grupo de ECUs
ou da ECU específica que vai receber a mensagem.
35
2.5 DESENVOLVIMENTO DE UM DATABASE
Hu et al. (HU et al., 2007) elucidam em seu trabalho os passos básicos para a
criação de um Database baseado no SAE J1939. Os autores usaram três tabelas de
apoio para o desenvolvimento. Essas tabelas estão mostradas na figura 18.
Figura 18 – Tabelas usadas para o desenvolvimento do banco de

dados de Hu et al.
Fonte: (HU et al., 2007)
Um processo similar também é feito por Pizyblski (PIZYBLSKI, 2017). O pri-

meiro passo em ambos os trabalhos é definir quais sinais se deseja transmitir, depois
procurar o respectivo SPN no documento SAE J1939/71. Através do SPN é possível
encontrar em qual mensagem aquele sinal está contido. Isso é possível graças ao
PGN da mensagem.
Uma vez que os sinais e as mensagens estão devidamente ordenados, o pró-
ximo passo é olhar os valores de offset, data range, resolução, entre outros dados
contidos no documento SAE J1939/71 e então usar um editor de banco de dados
para criar as mensagens. Em Hu et al. os programas utilizados são o Delphi e o SQL
Server2000, enquanto que Pizyblski utiliza o BUSMASTER®.
Através das tabelas na figura 18 é mais fácil organizar esse desenvolvimento.
2.6 DESENVOLVIMENTO DE UMA REDE CAN
Em relação ao desenvolvimento de redes CAN, pode-se dizer que há atual-

mente duas principais abordagens: a abordagem clássica, com desenvolvimento em
linguagem de alto nível, como C e C++, ou a abordagem de desenvolvimento baseado
36
em modelos. Para a primeira abordagem utiliza-se compiladores e software de desen-

volvimento para microcontroladores como o MPLAB e o ARDUINO IDE, enquanto que
a segunda abordagem é possível de ser feita em ambientes computacionais como o
Matlab/Simulink®.
2.6.1 Desenvolvimento clássico
Souza (SOUZA, 2013) desenvolveu em seu trabalho a abordagem clássica

utilizando controlador PIC18F4580, sendo o desenvolvimento feito com linguagem C.
Guimarães (GUIMARãES, 2007) mostrou em seu trabalho um roteiro de implementa-
ção de uma rede CAN sendo esse baseado no desenvolvimento clássico, assim como
Souza.
Nos dois trabalhos os passos seguidos são semelhantes. Guimarães diz que
a programação de uma rede CAN dentro de uma ECU está armazenada na memória
RAM da mesma. Esse programa é que implementa rotinas essenciais para a comuni-
cação na rede CAN. São essas rotinas:
• Inicialização da porta de comunicação CAN;
• Rotina de transmissão e recepção via CAN;
• Rotina de leitura de uma entrada digital;
• Rotina de acionamento de uma saída digital.
Assim, o exemplo de código utilizado em Guimarães está esquematizado no

algoritmo 1:
Algoritmo 1 – Algoritmo de desenvolvimento de uma rede CAN

inserir 87C591.h
1: Define a estrutura da mensagem CAN
2: Inicia a porta RS232
3: Define a transmissão via CAN
4: Define a recepção via CAN
5: imprime Mensagem
Fonte: (GUIMARãES, 2007)
37
2.6.2 Desenvolvimento baseado em modelos
O desenvolvimento baseado em modelos, do inglês Model-based Design

(MBD), visa fazer com que o desenvolvimento aconteça de forma mais rápida, intuitiva
e com maior reaproveitamento de trabalho feito.
O MBD é um método de modelagem matemático e visual para desenvolver
sistemas complexos (NEME; SANTOS; TEIXEIRA, 2015). Segundo Silva et al. (SILVA
et al., 2017), o MBD é importante em diversos ramos da engenharia como o automo-
tivo, o aeroespacial, de equipamentos industriais, entre vários outros. Isso acontece
pois esse método diminui drasticamente os gastos de testes feitos em veículos re-
ais. O MBD se vale de uma metodologia de desenvolvimento baseada no modelo V e
assim ele segue passos bem definidos antes de chegar aos testes em unidades com-
pletas, como afirmado por Broy et al. (BROY et al., 2013). O modelo V é apresentado
na figura 19.
Figura 19 – Desenvolvimento segundo o modelo V
Fonte: (BAKER, 2016)
Como dito por Silva et al. (SILVA et al., 2017), o primeiro passo no MBD é
reunir os desejos e requisitos de alto nível do projeto e transformá-los em requisitos
de projeto. Depois disso segundo (SILVA, 2017), vem a parte de desenvolvimento de
software que passa pelas etapas de Model-In-The-Loop (MIL), Software-In-The-Loop
(SIL), Processor-In-The-Loop (PIL) e por último Hardware-In-The-Loop (HIL). A seguir
está uma breve explicação dessas etapas:
• MIL: fase para verificar a eficácia do modelo teórico desenvolvido quando sob
estímulo de sinais de entrada no sistema. Serve para verificar, por exemplo, se a
estratégia de controle adotada em um problema dará bons resultados.
38
• SIL: pertencente a etapa de verificação e validação. Aqui controlador é conver-

tido em código fonte em linguagem C, por exemplo (SILVA, 2017).
• PIL: o código fonte gerado na etapa anterior, caso tenha passado nos testes, é
embarcado no controlador a ser utilizado. A Planta ainda permanece em forma
de modelo.
• HIL: nessa etapa tanto controlador como planta estão embarcados. A planta
pode estar em um simulador ou ser real. Segundo Silva (SILVA, 2017), o objetivo
do HIL é verificar a integração entre os sistemas de hardware e software.
Para a realização desse método, alguns programas de computador são muito

importantes como é o caso do IBM DOORS para o gerenciamento de requisitos e o
Matlab/Simulink® para o desenvolvimento de software propriamente dito. Por exem-
plo, Erkkinen et al. (ERKKINEN et al., 2011), Erkkinen (ERKKINEN, 2009) e Franco
(FRANCO et al., 2016) usam o Matlab/Simulink® em seus trabalhos de MBD.
A metodologia MBD é vantajosa em muitos sentidos às montadores de auto-
móveis. Na figura 20 mostra-se uma bancada de desenvolvimento para um modelo
GOLF da Volkswagen AG. Os testes de HIL, por exemplo, são todos realizados em
uma bancada como na figura 20 antes de serem feitos em veículos reais.
Figura 20 – Bancada para desenvolvimento de software automotivo

de um modelo Golf

39
2.7 LEITURA DE DADOS NA REDE CAN: FERRAMENTAS MAIS UTILIZADAS
O processo de leitura dos dados contidos em uma rede CAN é relativamente

simples. Atualmente os protocolos que regem a implementação da rede não preveem
a criptografia das mensagens, sendo assim é possível obter os dados através do sim-
ples fato de acessar fisicamente o barramento da rede (através dos fios CAN_H e
CAN_L). Entretanto, é necessário o uso de uma interface entre o barramento e o com-
putador e ainda um programa de computador específico para leitura e manipulação de
mensagens. Basicamente, a interface "traduz" os níveis de tensão do barramento em
informações úteis ao programa de leitura.
Algumas das interfaces e programas mais utilizados no setor automotivo estão
brevemente descritos abaixo.
2.7.1 CANoe e família Vector
O CANoe® é um ambiente de desenvolvimento, teste e análise universal para

sistemas com barramento CAN (VECTOR, 2010). As possibilidades de desenvolvi-
mento através desse software são inúmeras. É possível, por exemplo, criar ECUs
virtuais e fazê-las interagir com ECUs físicas, essa possibilidade facilita o desenvolvi-
mento de novas funções ou novas ECUs. Além disso, o programa lê e escreve sinais
no barramento e pode também simular a troca de mensagens com outras redes, como
por exemplo a FlexRay. A figura 21 mostra a interface do programa.
Figura 21 – Interface do CANoe
Fonte: (VECTOR, 2018)
Existem diversas interfaces produzidas pela Vector GmbH que fazem a ligação
40
física do barramento com o computador. As mais consagradas na indústria automotiva

são: CANcaseXL, VN1600 e o VN1610 (VECTOR, 2010). A figura 22 mostra o VN1610
da Vector GmbH.
Figura 22 – Interface VN1610
Fonte: (VECTOR, 2017)
2.7.2 BUSMASTER®
O BUSMASTER® é um software de fonte aberta criado da parceria entre as

empresas ETAS GmbH e Robert Bosch Engineering and Business Solution LTDA. O
objetivo do desenvolvimento desse software foi a de criar um programa open source
para design, monitoramento, simulação e análise de sistemas de rede CAN (LORENZ;
ANDREW, 2011). Apesar de não ter uma interface tão amigável ao usuário quanto o
CANoe®, o programa possui diversas funções semelhantes a este como descrito em
(RBEBS LTDA, 2011):
• Tela de mensagens;
• Informação e interpretação de mensagens;
• Filtros;
• Logging;
• Reprodução de mensagens adquiridas no logging;
• Estatísticas das redes;
• Signal watch e muitas outras funções.

41
A figura 23 mostra a tela inicial do programa.

Figura 23 – Tela inicial do BUSMASTER®
2.7.3 KVASER Leaf Light v2
O KVASER® assim como o VN1610 da Vector, é uma interface entre o com-

putador e o barramento CAN. No BUSMASTER® é possível, entre outras ferramentas,
usar o KVASER®. Esse dispositivo é um dos que possuem o melhor custo-benefício
de sua classe no mercado (KVASER, 2018). A figura 24 mostra como é o dispositivo.
Figura 24 – Kvaser Leaf Light v2
Fonte: (KVASER, 2018)
2.8 ARQUITETURA DE ECUS NO CAMINHÃO VOLVO FH
A arquitetura de ECUs, por ser proprietária de cada montadora, é difícil de

ser encontrada na literatura. Entretanto, Marinho & Cordeiro (MARINHO; CORDEIRO,
42
2013) realizaram um estudo em parceria com a Volvo do Brasil, onde utilizaram os

módulos eletrônicos do caminhão Volvo FH.
Nesse trabalho os autores dividem a arquitetura do Volvo FH em três gran-
des grupos, separados conforme as propriedades funcionais (MARINHO; CORDEIRO,
2013):
• Unidades de controle com segurança crítica: nesse grupo estão contidas as

ECUs de powertrain e veículo, que são gerenciamento de motor (EMS), trans-
missão (TECU) e de veículo (VECU).
• Unidades de controle com segurança passiva: fazem parte desse grupo as

unidades de conforto como airbags (SRS), telemática (Dynafleet) e climatização
(STD e MCC).
• Unidades de controle para entretenimento: estão nesse grupo unidades que

gerenciam, por exemplo, telefone, rádio e áudio.
O conhecimento dessa arquitetura é essencial para este trabalho, uma vez

que sabe-se através disso que as ECUs disponíveis no laboratório são interligadas
por uma única rede. Além disso, existem ainda particularidades da norma SAE J1939
que foram criadas pela Volvo por conveniência em seus projetos.
43
3 MATERIAIS E MÉTODOS
Este trabalho tem caráter qualitativo, explicativo e de estudo de caso. Para a

elaboração desse documento os passos descritos na figura 25 foram seguidos. As eta-
pas mostradas na figura 25 estão descritas detalhadamente nas subseções seguintes.
Figura 25 – Etapas do desenvolvimento do trabalho

Levantar as Desenvolver
Realizar
Delimitar hipóteses a melhor
pesquisa
o tema para solução solução
bibliográfica
do problema encontrada
Testar o
método
Escrever os
resultados
obtidos
Para a realização do trabalho foram necessários os seguintes materiais e pro-

gramas de computador:
• Bancada com ECUs, painel de instrumentos e tacógrafo do caminhão Volvo

FH12;
• Interface KVASER® para coleta de sinais do barramento CAN;
• Laptop;
• Osciloscópio;
• Multímetro;
• O software BUSMASTER®;
• O software Matlab/Simulink®.
44
3.1 DELIMITAÇÃO DO TEMA
A delimitação do tema aconteceu de tal forma que o estudo realizado fosse

condizente com o modelo de desenvolvimento que acontece nas montadoras de veí-
culos. Para isso, foi necessário analisar quais eram os recursos disponíveis no labo-
ratório que mais se assemelham aos recursos disponíveis nas OEMs. A partir disso,
buscou-se então o estado da arte do tema o que culminou na pesquisa bibliográfica,
descrita a seguir.
3.2 PESQUISA BIBLIOGRÁFICA
A fim de dar um embasamento científico ao trabalho, diversas bibliografias fo-

ram revisadas. Primeiramente, abordou-se o tema eletrônica automotiva e a crescente
importância desta na industria e como há a necessidade de redes de comunicação em
veículos. Para isso, utilizou-se os seguintes descritores em língua inglesa nas bases
científicas de dados: trends in the automotive industry, future of communication
systems for the automotive industry e automotive networks in 10 years. Os des-
critores em português foram: tendência para o mercado automotivo, futuro das
redes automotivas e redes de comunicação automotiva em 10 anos. A segunda
abordagem foi a de levantar o estado da arte das redes automotivas em funciona-
mento. Para isso, utilizou-se os descritores automotive networks, Controller Area
Network , development of a data-base of a CAN network , Controller Area Network
and Simulink , SAE J1939 Development in a Simulink environment, Schedula-
bility Analysis Controller Area Network e Jitter Requirements Controller Area
Network em língua inglesa, sendo os mesmos descritores utilizados em língua portu-
guesa. Assim, um embasamento teórico sobre redes de comunicação, redes automo-
tivas, rede CAN, banco de dados e desenvolvimento de redes no setor automotivo foi
feito. Esse passo foi importante, pois dá forma científica ao trabalho.
Por fim, abordou-se as técnicas usadas nesse documento e as comparou com
a literatura.
45
3.3 LEVANTAMENTO DE HIPÓTESES
Feita a pesquisa, foi então elaborada a hipótese que melhor solucionaria o

problema, do ponto de vista do autor e baseada na literatura.
A melhor configuração encontrada é apresentada na figura 26. Aqui nota-se
que será criado um nó virtual que irá interagir com os nós verdadeiros do sistema.
Toda a informação do nó virtual será criada, inclusive o banco de dados utilizada, que
será baseado no padrão SAE J1939/71. A partir desse setup de montagem é possível
obter resultados importantes como, por exemplo, a influência de novas mensagens no
barramento.
Figura 26 – Proposta de execução
Essa proposta mostrou-se muito semelhante à utilizada na indústria e era pos-

sível de ser realizada com os equipamentos disponíveis.
3.4 DESENVOLVIMENTO
As etapas de desenvolvimento estão descritas de maneira cronológica a se-

guir.
46
3.4.1 Criação do banco de dados
Para a criação do banco de dados foi utilizado o software BUSMASTER® e a

norma SAE J1939/71. Para isso, foi necessário seguir alguns passos, como descrito
na sequência.
O primeiro passo é definir quais sinais e mensagens do SAE J1939/71 serão
criados. É necessário procurar nesse documento quais sinais estão mapeados dentro
de quais mensagens, visto que uma mensagem pode carregar vários sinais. Depois
disso, é preciso abrir o BUSMASTER®, ir na aba CAN, selecionar o campo Database
e então selecionar o comando New, conforme mostrado na figura 27. Esse processo
irá criar o banco de dados.
Figura 27 – Passos para criação do banco de dados - Parte I
Uma vez que as informações de PGN e do SPN estão disponíveis no do-

cumento da norma, o próximo passo consiste em colocar os dados de cada sinal,
conforme mostrado na figura 28. Depois é preciso apenas incluir novas mensagens
no database criado.
3.4.2 Simulação CAN através do Matlab/Simulink
Uma vez que o banco de dados estava criado, foi possível seguir para o pró-
ximo passo do trabalho que consistia na modelagem de uma rede CAN através do
Matlab/Simulink. Para isso, foi necessário usar a Vehicle Network Toolbox, onde os
blocos de comunicação de rede CAN estão disponíveis. O modelo da figura 29 foi de-
senvolvido no Grupo de Sistemas Automotivos da UTFPR-PG para manipulação de
47
Figura 28 – Passos para criação do banco de dados - Parte II
dados da rede CAN e tem base na teoria descrita por (NEME; SANTOS; TEIXEIRA,
2015).
Figura 29 – Bloco de Simulink para Injetar Mensagens no Barra-

mento
Na figura 30 mostra-se um exemplo de um bloco Function Call onde é escrita

uma mensagem CAN.
Figura 30 – Mensagem de Velocidade sendo escrita

48
3.5 TESTES E AQUISIÇÃO DE DADOS
Para a realização dos testes foi necessário então o uso da bancada mostrada
na figura 31. A configuração utilizada foi exatamente como a representada, ou seja
com o emprego de um computador, do KVASER e de um osciloscópio. Na figura 32 é
possível ver a distribuição das ECUs na parte de trás do painel. Todos os instrumentos
da figura 32 estão conectados no mesmo barramento.
Figura 31 – Bancada e materias utilizados nos testes
Figura 32 – Distribuição dos instrumentos do painel
O procedimento de testes e aquisição de dados aconteceu da seguinte ma-

neira:
49
• Primeiro conectou-se o laptop ao barramento CAN através da interface KVA-

SER®. O acesso ao barramento se dá através de um conector DB-9.
• Depois conectou-se o osciloscópio à rede da seguinte maneira: o terra da pon-

teira foi colocado em ligação direta no fio CAN_L do barramento. A ponta positiva
foi conectada diretamente ao fio CAN_H do barramento. Desta maneira o sinal
medido no osciloscópio foi constituído da diferença de potencial entre os fios
CAN_H e CAN_L, como na figura 8.
• Uma vez que as ligações físicas estavam prontas, foi então iniciada a leitura do
barramento com o software BUSMASTER.
• Depois disso, foi possível então escrever mensagens no barramento através do

Simulink. Também foram injetadas mensagens através do estímulo dado no pe-
dal de acelerador do painel.
• Assim que todas as etapas anteriores foram cumpridas e constatou-se que o

setup estava correto, então associou-se o database criado com os sinais lidos e
fez-se a aquisição das mensagens através do processo de logging.
• Uma segunda medição com o osciloscópio foi feita em outra configuração. Dessa
vez o osciloscópio foi colocado nos pinos dois e oito do conector do pedal. O
Multímetro foi utilizado nos mesmos pinos para verificar se a oscilação de ten-
são estava dentro dos padrões necessários. Ao mesmo tempo dessa medição,
também foi adquirido o sinal do pedal através do BUSMASTER®.
• A última etapa foi então a obtenção de informações úteis em forma de gráfico

através do próprio recurso específico do BUSMASTER e de rotina escrita no
Matlab. A rotina está disponível no apêndice A.
3.6 ESCRITA
A fase de escrita consistiu na reunião de bibliografias, técnicas, fotos, dados e

resultados em documento. Essa fase é importante para mostrar a revisão da bibliogra-
fia, o método utilizado, os dados coletados e a comparação destes com a literatura.
50
4 RESULTADOS E DISCUSSÃO
A medição feita no barramento antes da associação de um dicionário de da-

dos aconteceu como na figura 33. O BUSMASTER® lê as mensagens que estão no
barramento, porém não consegue traduzir os dados recebidos em informação útil.
Figura 33 – Mensagens lidas no barramento antes da associação de um dici-

onário de dados
Depois que a associação do database é feita, as mesmas mensagens que

estavam no barramento anteriormente aparecem na figura 34. É possível observar que
agora, uma vez que se pretenda analisar os dados no barramento, isso acontecerá de
forma mais fácil. Assim como em (PIZYBLSKI, 2017) e em (HU et al., 2007), observa-
se aqui a importância de um dicionário de dados, pois não seria possível trabalhar os
dados sem houve uma "tradução" desta para algo do entendimento humano.
Figura 34 – Mensagens no barramento depois da utilização do dicionário de

dados
Depois que o database foi associado é possível observar por dentro de uma
mensagem e buscar os valores de cada sinal que está dentro de uma mensagem,
como mostrado na figura 35.
51
Figura 35 – Sinais lidos no barramento
Uma vez que isso foi feito, uma medição foi realizada no sinal do pedal, pois
ele é o único na bancada que pode ser medido em duas fases: puro e no barramento.
A figura 37 mostra o sinal analógico puro medido diretamente nos fios através de um
osciloscópio. Observa-se que o sinal é invertido do sinal do lido na figura 36, que é o
sinal lido no barramento CAN. O sinal puro do pedal acontece da seguinte maneira:
há uma diferença de potencial entre os pinos do pedal de 4,7V, esse valor de 4,7V
corresponde ao 0% do pedal. A diferença de potencial varia até 1,7V, que corresponde
ao 100% do sinal do pedal.
Em relação aos atrasos de mensagem estudados em (ARKESTEIJN; KLUM-
PERINK; NAUTA, 2006), (TINDELL; HANSSON; WELLINGS, n.d.) e (DAVIS et al.,
2007), os dados coletados das figura 37 e figura 36 poderiam ser analisados juntos
para se comprovar o jitter total do sinal. Entretanto é necessário que haja uma sincro-
nia de clock entre os dispositivos de medição. Idealmente, a aquisição de dados deve
ser feita pelo mesmo dispositivo (computador, por exemplo) e com interfaces diferen-
tes. Como sugestão, poderia ser usada a interface DIC6B da família DATaRec4® da
Zodiac Data Systems GmbH para aquisição do sinal puro e usar a mesma interface
do experimento, a KVASER®, para o sinal no barramento.
Depois disso foi utilizado o modelo do Simulink mostrado na figura 29 para
injetar um maior número de mensagens na rede para ser possível uma análise de
jitter. Os sinais que foram escritos na rede através de mensagens criadas no Simulink
aparecem na figura 38. Nesse processo, o Simulink leu a mensagem de posição de
pedal e pela lógica criada, injetou uma mensagem proporcional de velocidade, ou
seja, quando a posição do pedal era de 0%, o valor de velocidade enviado era de 0
Quilômetros por hora (km/h) e quando o pedal estava em 100%, o valor da velocidade
era 120 km/h. Essa configuração foi feita para cobrir todos os valores de velocidade
52
Figura 36 – Sinal da posição do pedal aquirido através de uma men-

sagem CAN
Figura 37 – Sinal da posição do pedal adquirido diretamente nos pi-

nos do pedal
do painel do veículo, uma vez que o painel registra até 120 km/h.
Figura 38 – Gráficos no Simulink de saída
O frame medido dessa variação está mostrado nas figuras 39 e 40. É possível
ver que a mensagem está no mesmo padrão descrito em (BAEKER, 2014), (GUIMA-
RãES, 2007) e (VECTOR, 2010). O ID nos dois sinais é o mesmo, entretanto o campo
53
de dados muda nas duas mensagens, o que comprova que o sinal foi alterado com
sucesso pelo Matlab/Simulink.
Figura 39 – Sinal visto pelo osciloscópio com valor igual a 0
Figura 40 – Sinal visto pelo osciloscópio com valor igual a 100
Utilizando o recurso de análise gráfico do BUSMASTER® da mesma forma

que em (SILVA, 2015), (PIZYBLSKI, 2017) e (RBEBS LTDA, 2011), foi possível com-
parar os sinais da posição do pedal e de aceleração usados pelo Simulink. O resultado
está mostrado na figura 41, onde o sinal do pedal está em azul e o sinal de velocidade
em verde.
Comprovado então que o modelo da figura 29 estava funcionando como o
esperado, foi então iniciada uma aquisição de todas as mensagens que estavam no
barramento. Essa aquisição foi feita através do logging. Na figura 42 mostra-se um
exemplo do log feito. Esses dados são importantes para se fazer a análise de jitter de
54
Figura 41 – Sinais de pedal e velocidade lidos no Busmaster®
uma mensagem. O algoritmo escrito no Matlab para a análise de jitter das mensagens
está no apêndice A.
Figura 42 – Log com todas as mensagens do barramento CAN
O mesmo log foi análisado para a mensagem VP2_X_V que carrega entre
outros, o sinal da posição do pedal. O critério da escolha da mensagem foi o de im-
portância. A informação de posição de pedal é importante em situações de risco. Na
figura 43 foi observado através do time stamp da mensagem que há uma variação
no tempo de entrega da mensagem. No exemplo dessa figura observa-se que há uma
quantidade menor de mensagens no barramento e a VP2_X_V chega a ter um período
de 90 ms.
A partir dessa observação gerou-se então o gráfico da figura 44 que repre-
55
Figura 43 – Observação do Time Stamp da Mensagem VP2_X_V
senta o tempo entre a entrega de um frame e outro de uma mesma mensagem. Na

figura é possível quer o que período da mensagem é de 100 ms, sendo que há vari-
ações entre a entrega de mensagens de 10 ms e 20 ms para mais ou para menos. É
possível ver no gráfico que há períodos onde há uma intensa variação no tempo de
entrega das mensagens. Esses períodos de intensa variação acontecem nos momen-
tos onde o barramento está mais carregado através da injeção de sinais através do
Simulink.
Figura 44 – Variação do atraso na entrega da mensagem VP2_X_V
Diferença no Período de Recebimento da Mensagem VP2 X V
120
110
Diferença entre a entrega de um frame e outro (em ms)
100
90
80
70
60
50
40
30
20
0 0.5 1 1.5 2 2.5 3

Número de Mensagens (em unidades) ×10 4
Na figura 45 foi feita a aproximação de um dos períodos de intensa variação

no tempo de entrega dos pacotes. É possível ver que o jitter nesse pedaço observado
do gráfico é de 10 ms para mais ou para menos. Ou seja, a mensagem é entrega a
56
cada 110 ms ou 90 ms.

Figura 45 – Zoom de um período com muito jitter da mensagem
VP2_X_V
Diferença no Período de Recebimento da Mensagem VP2 X V
115
Diferença entre a entrega de um frame e outro (em ms)

110
105
100
95
7200 7400 7600 7800 8000 8200 8400

Número de Mensagens (em unidades)
Esses resultados observados de jitter são importantes para aplicações onde

se necessita usar informações para que um software tome uma decisão. Para tal soft-
ware recomenda-se, sempre que possível, a utilização do sinal obtido diretamente na
ECU através do uso de protocolos próprios para isso, como por exemplo o CCP e o
XCP.
57
5 CONCLUSÕES E PERSPECTIVAS
A eletrônica embarcada em automóveis tem crescido nos últimos 30 anos e

a utilização de redes de comunicação tem contribuído para isso, pois elas reduzem
peso, espaço utilizado e custos. As redes devem em contrapartida oferecer requisitos
mínimos de segurança e velocidade e nessas questões ainda há um vasto campo de
investigação científica.
Este trabalho teve como objetivo principal desenvolver uma rede de comuni-
cação automotiva no padrão SAE J1939 desde a criação de um dicionário de dados
até a análise temporal das mensagens lançadas na rede para se entender o processo
e mostrar campos de possível melhoria no tema. Mostrou-se também a importância
e os métodos de uso das ferramentas corretas para a leitura e manipulação de uma
rede CAN.
Além disso, a análise temporal mostrou que há um atraso significativo na pro-
dução de um sinal e o envio deste em forma de mensagem aos destinos. Essa conclu-
são pode ser de grande proveito quando, por exemplo, se deseja utilizar os dados dis-
poníveis na rede para aplicações no automóvel (por exemplo autonomous cars, etc).
Para aplicações como essas descritas, recomenda-se o uso das informações contidas
diretamente nas ECUS. Essas informações podem ser obtidas através de protocolos
de acesso a ECUs, como por exemplo o protocolo XCP.
Para trabalhos futuros há ainda vários temas em aberto. Sugere-se, por exem-
plo, investigar mais de perto os efeitos de jitter na rede, começando a análise desde o
momento da transdução da grandeza física em sinal elétrico até a transmissão com-
pleta do sinal ao seu destino. Ainda é possível fazer toda a análise desse trabalho para
uma rede determinística ou ainda mesmo fazê-la para a nova geração da rede CAN:
a CAN-FD. A figura 46 mostra uma sugestão de configuração do autor para a realiza-
ção da comparação direta do sinal analógico do pedal com o sinal lido no barramento
CAN.
Na figura 46 observa-se o setup de montagem sugerido, onde colocou-se para
a leitura do sinal analógico um osciloscópio e um uma placa de aquisição de dados
NI DAQ USB-6212. A interface KVASER recebe ao mesmo tempo os dados do pedal
através do barramento CAN. Além dessa configuração, é possível ver na figura os
58
Figura 46 – Configuração para testes em trabalhos futuros
resultados dos gráficos obtidos nos aparelhos de medição.

59
REFERÊNCIAS
ARKESTEIJN, Vincent J.; KLUMPERINK, Eric A. M.; NAUTA, Bram. Jitter

requirements of the sampling clock in software radio receivers. IEEE TRANSACTIONS
ON CIRCUITS AND SYSTEMS, v. 53, n. 2, p. 90–94, fev. 2006. Citado 3 vezes nas
páginas 30, 31 e 51.
BAEKER, Bernard. Automobil Electronics and Mechatronics. 2014. Vorlesung TU

Dresden. Citado 6 vezes nas páginas 14, 15, 23, 26, 38 e 52.
BAKER, Loyd. Executives Will Want to use MBSE: The value of mbse to a non -
engineer. Washington DC, EUA: [s.n.], 2016. Citado na página 37.
BERNARDESCHI, Cinzia et al. Modeling and generation of secure component

communications in autosar. SAC ’17 Proceedings of the Symposium on Applied
Computing, Marraquexe, Morroco, p. 1473–1480, abr. 2017. Citado na página 15.
BORDOLOI, Unmesh D.; SAMII, Soheil. The frame packing problem for can-fd. IEEE
Real-Time Systems Symposium (RTSS), n. 1, p. 284–293, fev. 2014. Citado na
página 15.
BROY, Manfred et al. What is the benefit of a model-based design of embedded

software systems in the car industry?: Software design and development: Concepts,
methodologies, tools, and applications. IGI Global, p. 310, 2013. Citado na página 37.
CORRIGAN, Steve. Controller Area Network Physical Layer Requirements:

Application report. [S.l.], 2008. Citado na página 24.
DAVIS, Robert I. et al. Controller area network (can) schedulability analysis: Refuted,
revisited and revised. Real-Time Systems, n. 1, p. 239–272, 2007. Citado 2 vezes
nas páginas 32 e 51.
ERKKINEN, Tom. Fixed-point ecu code optimization and verification with model-based
designt. SAE, n. 6, p. 1–6, jan. 2009. ISSN 0148-7191. Citado na página 38.
60
ERKKINEN, Tom et al. On-target rapid prototyping: A practical approach for

bootstrapping production ecu software development. Mathworks, Mathworks, n. 1,
p. 1–8, jan. 2011. Citado na página 38.
FOROUZAN, Behrouz A. Comunicação de Dados e Redes de Computadores. São

Paulo, Brasil: Editora McGraw-Hill, 2008. 1133 p. Citado 2 vezes nas páginas 19 e 21.
FRANCO, Felipe et al. Teaching model-in-the loop: A case study for controller of
distributed dashboard in a road vehicle. IEEE Industrial Electronics, IEEE, p.
863–868, jun. 2016. Citado na página 38.
GUIMARãES, Alexandre A. Eletrônica Embarcada Automotiva. São Paulo, Brasil:

Editora Érica, 2007. 328 p. Citado 3 vezes nas páginas 25, 36 e 52.
HU, Jian et al. Design and application of sae j1939 communication database in
city-bus information integrated control system development. IEEE International
Conference on Mechatronics and Automation, n. 1, p. 3429 – 3434, ago. 2007.
Citado 2 vezes nas páginas 35 e 50.
ISO11898/TC22/SC31. Road Vehicles: Controller area network. [S.l.], 2015. Citado

na página 15.
ISO17458. Road Vehicles: Communication on flexray. [S.l.], 2010. Citado na página

15.
ISO/TC22/SC31. Road Vehicles: In-vehicle ethernet. [S.l.], 2010. Citado na página

15.
JUNGER, Markus. Introduction to J1939: Version 1.1. [S.l.], 2010. Citado na página
33.
KVASER. Kvaser Leaf Light HS v2. 2018. <https://www.kvaser.com/product/

kvaser-leaf-light-hs-v2/>. Acessado: 24.05.2018. Citado na página 41.
LIU, H.; AN, J.-P.; YANG, J. Vehicle network communication protocol - a case of
study. n.d. Citado na página 22.
61
LORENZ, Tobias; ANDREW, Borg. BUSMASTER -An Open Source Tool. [S.l.],
2011. Citado na página 40.
MARINHO, Arthur D.; CORDEIRO, Willian S. C. DESENVOLVIMENTO DE UMA

BOX TRUCK PARA REALIZAÇÃO DE TESTES ELÉTRICOS EM COMPONENTES
AUTOMOTIVOS. Curitiba, Brasil: [s.n.], 2013. Repositório UTFPR. Citado na página
42.
MERCER MANAGEMENT CONSULTING; FRAUNHOFER GESELLSCHAFT.

Future automotive industry structure (fast) 2015. In: MATERIALIEN ZUR
AUTOMOBILINDUSTRIE. Frankfurt, Alemanha, 2003. p. 32. Citado na página 14.
MOHR, D et al. The road to 2020 and beyond: What’s driving the global
automotive industry? 2013. McKinsey & Company. Citado na página 14.
NASSIN, Bessaad. Controller Area Network (CAN bus) in the Automotive

Industry: An efficient way to establish in-system communication. 2016. Citado na
página 29.
NATALE, Marco Di; SILVA, Celso L. M. Da; SANTOS, Max M. D. On the applicability
of an milp solution for signal packing in can-fd. IEEE Industrial Informatics (INDIN),
n. 1, p. 37–41, jul. 2016. Citado na página 15.
NAVET, Nicolas et al. Trends in automotive communication systems. Proceedings of

the IEEE, IEEE, v. 93, n. 6, p. 1204–1223, maio 2005. ISSN 10.1109. Citado 2 vezes
nas páginas 15 e 21.
NEME, João. H.; SANTOS, Max. M. D.; TEIXEIRA, Evandro L. S. Model based design
for automobile external lighting systems. 24th SAE Brasil International Congress
and Display, São Paulo, Brasil, n. 1, p. 1–11, set. 2015. Citado 2 vezes nas páginas
37 e 47.
PIZYBLSKI, Manoela G. ESTUDO DE FERRAMENTAS DE COMUNICAÇÃO DE

DADOS PARA MEDIÇÃO, CALIBRAÇÃO E TESTES EM SISTEMAS VEICULARES.
Ponta Grossa, Brasil: [s.n.], 2017. Repositório UTFPR. Citado 3 vezes nas páginas
35, 50 e 53.
62
RBEBS LTDA. Busmaster Help: An228. [S.l.], 2011. Citado 2 vezes nas páginas 40
e 53.
ROBERT BOSCH GMBH. CAN Specification: Version 2.0. [S.l.], 1991. Citado 2
vezes nas páginas 15 e 23.
. CAN with Flexible Data-Rate Specification: Version 1.0. [S.l.], 2012. Citado
na página 15.
SAE. Lin Network for Vehicle Applications Conformance Test. [S.l.], 2005. Citado
na página 15.
. SAE J1939/71: Recommended practice of a serial control and communications

vehicle network. [S.l.], 2005. Citado 3 vezes nas páginas 15, 17 e 34.
SANTOS, Max M. D. Redes de Comunicação Automotiva: Características,

tecnologias e aplicações. São Paulo, Brasil: Editora Érica, 2014. 224 p. Citado na
página 30.
SILVA, Celso L. M. et al. New approach of tools application for systems engineering
in automotive software development. WCX™ 17: SAE World Congress Experience,
Detroit, EUA, 2017. Citado na página 37.
SILVA, Rafael R. Projeto de controladores para um sistema de direção elétrica

utilizando a metodologia de projeto baseado em modelos. 2017. Dissertação
(Mestrado) — Universidade de Brasília, Brasília, Brasil, 2017. Citado 2 vezes nas
páginas 37 e 38.
SILVA, Rafael R. Da. Modelagem e análise de redes automotivas em ambiente

virtual. Brasília, Brasil: [s.n.], 2015. Repositório UnB. Citado 5 vezes nas páginas 20,
22, 24, 33 e 53.
SOUSA, Rafael V. de. CAN (Controller Area Network): uma abordagem para
automação e controle na área agricola. 2002. Dissertação (Mestrado) —
Universidade de São Paulo, São Carlos, Brasil, 2002. Citado na página 20.
63
SOUZA, Paulo V. De. Estudo e Elaboração de uma Rede CAN para Aplicação em
um Sistema Automotivo. Divinópilis, Brasil: [s.n.], 2013. Repositório CEFET-MG.
Citado na página 36.
TINDELL, K. W.; HANSSON, H.; WELLINGS, A.J. Analysing real-time communicati-

ons: Controller area network (can). Uppsala, Suécia, p. 1–5, n.d. Citado 2 vezes nas
páginas 32 e 51.
URUL, GÖKHAN. A FRAME PACKING METHOD TO IMPROVE THE SCHEDULA-

BILITY ON CAN AND CAN-FD. 2015. Dissertação (Mestrado) — MIDDLE EAST
TECHNICAL UNIVERSITY, Ankara, 2015. Citado na página 15.
VECTOR. CANoe User Manual: Version 7.5. [S.l.], 2010. Citado 5 vezes nas páginas
26, 28, 39, 40 e 52.
. VN1600 Interface Family Manual: Version 4.1. [S.l.], 2017. Citado na página
40.
VECTOR. Entwicklungs- und Testwerkzeug CANoe.J1939. 2018. <http:

//vector.com/vi_canoe_j1939_de.html>. Acessado: 21.05.2018. Citado na página 39.
ZIMMERMAN, Werner; SCHMIDGALL, Ralf. Bussysteme in der Fahrzeugtechnik:

Protokolle, standards und software architektur. Wiesbaden, Alemanha: Springer
Vieweg, 2006. 228 p. Citado na página 22.
APÊNDICES
65
APÊNDICE A – LINHA DE CÓDIGO PARA A ANÁLISE DOS SINAIS
27.05.18 08:46 C:\Users\user\Desktop\Engenh...\getData.m 1 of 2
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%% Script para criação de gráficos a partir do 'log'%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Celso Luiz Mendes da Silva - 26.05.2018 %
% Extração de Dados
fileID = fopen('BUSMASTERLogFile2.txt'); % Abre o arquivo de 'log'

C = textscan(fileID,'%s'); % Lê os dados do arquivo de 'log' e salva-os em uma célula
fclose(fileID); % Fecha o arquivo de 'log'
%% Separa o frame desejado
% Frame 0xCFF0211 - VP2_X_V
x=4;
y=1;
referencia=C{1}{4}; % Mostra qual frame procurar
tamanhoReferencia=length(referencia); % Mostra qual o tamanho do identificador do
frame desejado
while x<1045982
tamanho=length(C{1}{x}); % Pega o tamanho do frame atual para comparar com a

referência
if tamanhoReferencia == tamanho
if C{1}{x} == referencia
mensagens(1,y)=x; % Salva os índices de onde estão salvas as mensagens com

o ID da referência
result{1}{y} = strcat(C{1}{x-3}(4),C{1}{x-3}(5),C{1}{x-3}(6),C{1}{x-3}(7),
C{1}{x-3}(8),C{1}{x-3}(9),C{1}{x-3}(10),C{1}{x-3}(11),C{1}{x-3}(12),C{1}{x-3}(13)); %
Seleciona os dados de tempo de recebimento das mensagens C{1}{x}(1),C{1}{x}(2),C{1}{x}
(3),C{1}{x}(4),C{1}{x}(5),C{1}{x}(6),
y=y+1;
end
end
x=x+14;
end
clear x y
%% Calcula o periodo de entrega dos frames

d=1;
for x=2:30958
temp=etime(datevec(result{1}{x}),datevec(result{1}{x-1})); % Faz o delta t da

chegada de mensagens
if temp>0 % Laço criado para a achar falha no programa

66

Folder Scania Oil 2016 7

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Folder Scania Oil 2016 7

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

CELSO LUIZ MENDES DA SILVA

MODELAGEM E TESTE EM BANCADA DE UMA REDE DE

TRABALHO DE CONCLUSÃO DE CURSO

MODELAGEM E TESTE EM BANCADA DE UMA REDE DE

Trabalho de Conclusão de Curso apresen-

Orientador: Prof. Dr. Max Mauro Dias

MODELAGEM E TESTE EM BANCADA DE UMA REDE DE COMUNICAÇÃO NO

Este Trabalho de Conclusão de Curso foi apresentado às 10:00 de 08 de junho de

Prof. Dr. Max Mauro Dias Santos

Prof. Dr. Josmar Ivanqui Prof. Msc. Jeferson José Gomes

– O Termo de Aprovação assinado encontra-se na Coordenação do Curso –

MENDES DA SILVA, Celso Luiz. MODELAGEM E TESTE EM BANCADA DE UMA

A quantidade de componentes eletrônicos tem aumentado em automóveis ao longo

Palavras-chave: Redes Automotivas. CAN. SAEJ1939. Modelagem. Teste.

MENDES DA SILVA, Celso Luiz. MODELING AND TEST OF A COMMUNICATION

Keywords: Automotive Networks. CAN. SAEJ1939. Modeling. Test.

Figura 1 – Mudança nas áreas de desenvolvimento de tecnologia na indústria

Tabela 1 – Classes de redes automotivas . . . . . . . . . . . . . . . . . . . . . 22

kbps Kilobits por segundo

A indústria automotiva está em constante desenvolvimento e as exigências

Figura 1 – Mudança nas áreas de desenvolvimento de tecnologia na indústria

Fonte: Adaptado de (MERCER MANAGEMENT CONSULTING; FRAUNHOFER

Com o aumento da eletrônica embarcada em veículos, têm-se imediatamente

Redes de comunicação automotiva são importantes para o desenvolvimento

A implementação de uma rede de comunicação, apesar de parecer trivial, é

1.3 OBJETIVOS GERAIS

Mostrar o processo de desenvolvimento de redes de comunicação automotiva

1.4 OBJETIVOS ESPECÍFICOS

Os principais objetivos a serem atingidos até o final do presente trabalho são:

• Entender o processo e a importância da criação de um Database padronizado.

• Desenvolver um Database e Setups de testes rápidos para desenvolvimento de

uma rede CAN.

• Mostrar o desempenho da rede com as mensagens criadas.

• Elucidar o desenvolvimento com algumas das principais ferramentas disponíveis

Devido a importância do tema "redes automotivas" e principalmente da grande

1.7 ORGANIZAÇÃO DO TRABALHO

Este trabalho foi organizado de maneira a apresentar o conteúdo de forma

Esse capítulo é destinado a uma breve revisão dos conceitos de redes de

2.1 REDES DE COMUNICAÇÃO

Figura 2 – Configuração básica de uma rede de comunicação

Fonte: Adaptado de (FOROUZAN, 2008)

Como mencionado acima, para que se transmita dados entre dispositivos é

necessário que se estabeleçam regras de comunicação, assim surgem os padrões.

Figura 3 – Comunicação de dois dispositivos segundo o padrão

Fonte: (SOUSA, 2002)

ainda é possível fazer criptografia e compressão de dados, conforme a necessidade

2.2 REDES AUTOMOTIVAS

No setor automotivo o uso de redes de comunicação traz algumas vantagens

em aplicações de Infotainment. Devido essa grande diversidade na utilização das re-

Geralmente, automóveis apresentam mais de uma rede em funcionamento e

Figura 4 – Redes em funcionamento em um veículo de classe média

Fonte: Adaptado de (ZIMMERMAN; SCHMIDGALL, 2006)

2.3 O CONTROLLER AREA NETWORK (CAN)

Figura 5 – Construção física da CAN

Fonte: Autoria própria

A velocidade de transmissão de dados varia conforme a extensão do barra-

Fonte: Adaptado de (CORRIGAN, 2008)

As divisões do protocolo conforme o modelo OSI estão elucidados nas subse-

2.3.1 Camada Física

que os dispositivos desempenham para possibilitar a transmissão de dados.

Figura 7 – Diferenças de tensão entre os fios que geram bits no

Fonte: (GUIMARãES, 2007)