Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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 DECOMUNICAÇÃO NO PADRÃO SAE J1939
TRABALHO DE CONCLUSÃO DE CURSO
PONTA GROSSA
2018
CELSO LUIZ MENDES DA SILVA
MODELAGEM E TESTE EM BANCADA DE UMA REDE DECOMUNICAÇÃO NO PADRÃO SAE J1939
Trabalho de Conclusão de Curso apresen-tado como requisito parcial à obtençãodo título de Bacharel em Engenharia Ele-trônica, do Departamento de Eletrônica,da Universidade Tecnológica Federal doParaná.
Orientador: Prof. Dr. Max Mauro DiasSantos
PONTA GROSSA
2018
Ministério da EducaçãoUniversidade Tecnológica Federal do Paraná
Câmpus Ponta GrossaDiretoria de Graduação e Educação Profissional
Departamento de EletrônicaBacharelado em Engenharia Eletrônica
TERMO DE APROVAÇÃO
MODELAGEM E TESTE EM BANCADA DE UMA REDE DE COMUNICAÇÃO NOPADRÃO SAE J1939
por
CELSO LUIZ MENDES DA SILVA
Este Trabalho de Conclusão de Curso foi apresentado às 10:00 de 08 de junho de2018 como requisito parcial para a obtenção do título de Bacharel em EngenhariaEletrônica. O candidato foi arguido pela Banca Examinadora composta pelos profes-sores abaixo citados. Após deliberação, a Banca Examinadora considerou o trabalhoaprovado.
Prof. Dr. Max Mauro Dias SantosOrientador
Prof. Dr. Frederic Conrad Janzen Prof. Msc. Robson Moreira de OliveiraMembro Titular Membro Titular
Prof. Dr. Josmar Ivanqui Prof. Msc. Jeferson José GomesResponsá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 UMAREDE DE COMUNICAÇÃO NO PADRÃO SAE J1939. 2018. 66 f. Trabalho deConclusão de Curso (Bacharelado em Engenharia Eletrônica) – UniversidadeTecnológica Federal do Paraná. Ponta Grossa, 2018.
A quantidade de componentes eletrônicos tem aumentado em automóveis ao longodos 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 decomunicaçã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, surgemprotocolos 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çãodessa rede com uma bancada com ECUs reais, sendo isso parte de um processo dedesenvolvimento 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 COMMUNICATIONNETWORK OF SAEJ1939 STANDARD IN A WORKBENCH. 2018. 66 p. FinalCoursework (Bachelor’s Degree in Electronic Engineering) – Federal University ofTechnology – Paraná. Ponta Grossa, 2018.
The number of electronic devices are increasing in the automobiles over the years. Themore digital systems are part of a vehicle, the more complex data shall be transmittedbetween 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 managethe generated data from the vehicles. The Controller Area Network (CAN) is one ofthe established networks in the automotive industry, however its development processstill remains nowadays. Based on the CAN emerge protocols that specify even morethe data communication elements as the SAE J1939. For this reason, this work aimsto show development techniques for CAN based on the SAE J1939 protocol and alsoshow the interaction between this network with a workbench made by real ECUs, beingthis 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ústriaautomotiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figura 2 – Configuração básica de uma rede de comunicação . . . . . . . . . . 19Figura 3 – Comunicação de dois dispositivos segundo o padrão ISO/OSI . . . 20Figura 4 – Redes em funcionamento em um veículo de classe média . . . . . . 22Figura 5 – Construção física da CAN . . . . . . . . . . . . . . . . . . . . . . . . 23Figura 6 – Modelo ISO/OSI para uma rede CAN . . . . . . . . . . . . . . . . . 24Figura 7 – Diferenças de tensão entre os fios que geram bits no High-Speed CAN 25Figura 8 – Como são gerados os níveis lógicos em uma rede CAN 2.0 . . . . . 26Figura 9 – Diferenças de tensão entre os fios que geram bits no Low-Speed CAN 26Figura 10 – Pinagem do conector DB-9 para acesso a rede . . . . . . . . . . . . 26Figura 11 – Divisão de uma mensagem CAN . . . . . . . . . . . . . . . . . . . . 27Figura 12 – Frame CAN 2.0A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figura 13 – Frame CAN 2.0B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 14 – Exemplo de três nós que disputam o barramento . . . . . . . . . . . 30Figura 15 – Caminho seguido por um sinal desde a aquisição até o escalonamento 30Figura 16 – Sinal analógico seno que deve passar pelo processo de amostragem 31Figura 17 – Exemplo de um PGN . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figura 18 – Tabelas usadas para o desenvolvimento do banco de dados de Hu
et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figura 19 – Desenvolvimento segundo o modelo V . . . . . . . . . . . . . . . . . 37Figura 20 – Bancada para desenvolvimento de software automotivo de um mo-
delo Golf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figura 21 – Interface do CANoe . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Figura 22 – Interface VN1610 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Figura 23 – Tela inicial do BUSMASTER® . . . . . . . . . . . . . . . . . . . . . . 41Figura 24 – Kvaser Leaf Light v2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figura 25 – Etapas do desenvolvimento do trabalho . . . . . . . . . . . . . . . . 43Figura 26 – Proposta de execução . . . . . . . . . . . . . . . . . . . . . . . . . . 45Figura 27 – Passos para criação do banco de dados - Parte I . . . . . . . . . . . 46Figura 28 – Passos para criação do banco de dados - Parte II . . . . . . . . . . 47Figura 29 – Bloco de Simulink para Injetar Mensagens no Barramento . . . . . . 47Figura 30 – Mensagem de Velocidade sendo escrita . . . . . . . . . . . . . . . . 47Figura 31 – Bancada e materias utilizados nos testes . . . . . . . . . . . . . . . 48Figura 32 – Distribuição dos instrumentos do painel . . . . . . . . . . . . . . . . 48Figura 33 – Mensagens lidas no barramento antes da associação de um dicio-
nário de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Figura 34 – Mensagens no barramento depois da utilização do dicionário de dados 50Figura 35 – Sinais lidos no barramento . . . . . . . . . . . . . . . . . . . . . . . 51Figura 36 – Sinal da posição do pedal aquirido através de uma mensagem CAN 52Figura 37 – Sinal da posição do pedal adquirido diretamente nos pinos do pedal 52Figura 38 – Gráficos no Simulink de saída . . . . . . . . . . . . . . . . . . . . . . 52Figura 39 – Sinal visto pelo osciloscópio com valor igual a 0 . . . . . . . . . . . . 53Figura 40 – Sinal visto pelo osciloscópio com valor igual a 100 . . . . . . . . . . 53
Figura 41 – Sinais de pedal e velocidade lidos no Busmaster® . . . . . . . . . . 54Figura 42 – Log com todas as mensagens do barramento CAN . . . . . . . . . . 54Figura 43 – Observação do Time Stamp da Mensagem VP2_X_V . . . . . . . . 55Figura 44 – Variação do atraso na entrega da mensagem VP2_X_V . . . . . . . 55Figura 45 – Zoom de um período com muito jitter da mensagem VP2_X_V . . . 56Figura 46 – Configuração para testes em trabalhos futuros . . . . . . . . . . . . 58
LISTA DE TABELAS
Tabela 1 – Classes de redes automotivas . . . . . . . . . . . . . . . . . . . . . 22Tabela 2 – Extensão vs Taxa de Transmissão no Barramento . . . . . . . . . . 24Tabela 3 – Pinos do conector DB-9 para uma rede CAN . . . . . . . . . . . . . 27Tabela 4 – Exemplo de um SPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
LISTA DE ABREVIATURAS, SIGLAS E ACRÔNIMOS
ABREVIATURAS
kbps Kilobits por segundokm/h Quilômetros por horam MetrosMbps Megabits por segundorpm Rotações por minutoV Volts
SIGLAS
ACK AcknowledgementCAN Controller Area NetworkCAN-FD Controller Area Network with Flexible Data-RateCRC Cyclic Redundancy CheckDLC Data Length CodeECU Unidades de Controle Eletrônico, do inglês Electronic Control UnitsEOF End of FrameHIL Hardware-In-The-LoopID IdentifierIDE Identifier ExtensionIP Instrument PanelISO International Organization for StandardizationLIN Local Interconnect NetworkMBD Model-based DesignMIL Model-In-The-LoopOEM Original Equipment ManufacturerOSI Open Systems InterconnectionPGN Parameter Group NumberPIL Processor-In-The-LoopRTR Remote Transmission RequestSAE Sociedade dos Engenheiros Automotivos, do inglês Society of Automo-
tive EngineersSIL Software-In-The-LoopSOF Start of FrameSPN Suspect Parameter NumberWCBT Worst-case Blocking Time
WCQD Worst-case Queuing DelayWCRT Worst-case Response Time
ACRÔNIMOS
A/D Analógico-DigitalCAN_H CAN HighCAN_L CAN Low
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.1 TEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2 PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3 OBJETIVOS GERAIS . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4 OBJETIVOS ESPECÍFICOS . . . . . . . . . . . . . . . . . . . . . . 161.5 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.6 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.7 ORGANIZAÇÃO DO TRABALHO . . . . . . . . . . . . . . . . . . . 182 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . . 192.1 REDES DE COMUNICAÇÃO . . . . . . . . . . . . . . . . . . . . . 192.2 REDES AUTOMOTIVAS . . . . . . . . . . . . . . . . . . . . . . . . 212.3 O CONTROLLER AREA NETWORK (CAN) . . . . . . . . . . . . . . 232.3.1 Camada Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.2 Camada de Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2.1 Frame CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2.2 Arbitragem de mensagens . . . . . . . . . . . . . . . . . . . . . . . . 292.3.2.3 Requisitos temporais de uma rede CAN . . . . . . . . . . . . . . . . 292.4 SAE J1939 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.5 DESENVOLVIMENTO DE UM Database . . . . . . . . . . . . . . . . . . 352.6 DESENVOLVIMENTO DE UMA REDE CAN . . . . . . . . . . . . . . . . 352.6.1 Desenvolvimento clássico . . . . . . . . . . . . . . . . . . . . . . . . 362.6.2 Desenvolvimento baseado em modelos . . . . . . . . . . . . . . . . . 372.7 LEITURA DE DADOS NA REDE CAN: FERRAMENTAS MAIS
UTILIZADAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.7.1 CANoe e família Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 392.7.2 BUSMASTER® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.7.3 KVASER Leaf Light v2 . . . . . . . . . . . . . . . . . . . . . . . . . . 412.8 ARQUITETURA DE ECUS NO CAMINHÃO VOLVO FH . . . . . . . . . . 413 MATERIAIS E MÉTODOS . . . . . . . . . . . . . . . . . . . . . . . . 433.1 DELIMITAÇÃO DO TEMA . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2 PESQUISA BIBLIOGRÁFICA . . . . . . . . . . . . . . . . . . . . . . . . 443.3 LEVANTAMENTO DE HIPÓTESES . . . . . . . . . . . . . . . . . . . . . 453.4 DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.4.1 Criação do banco de dados . . . . . . . . . . . . . . . . . . . . . . . 463.4.2 Simulação CAN através do Matlab/Simulink . . . . . . . . . . . . . . 463.5 TESTES E AQUISIÇÃO DE DADOS . . . . . . . . . . . . . . . . . . . . . 483.6 ESCRITA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 RESULTADOS E DISCUSSÃO . . . . . . . . . . . . . . . . . . . . . 505 CONCLUSÕES E PERSPECTIVAS . . . . . . . . . . . . . . . . . . . 57
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59APÊNDICES 64APÊ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ústriaautomotiva
Fonte: Adaptado de (MERCER MANAGEMENT CONSULTING; FRAUNHOFERGESELLSCHAFT, 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ãoISO/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 áudioB 10 kbps a 125 kbps Sensores, atuadores, painel, etcC > 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,00100 0,50200 0,25500 0,101000 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 noHigh-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 CAN2.0
Fonte: (BAEKER, 2014)
Figura 9 – Diferenças de tensão entre os fios que geram bits noLow-Speed CAN
Fonte: Adaptado de (VECTOR, 2010)
Figura 10 – Pinagem do conector DB-9 para acesso a rede
Fonte: (BAEKER, 2014)
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 ReservadoPino 2 CAN_LPino 3 TerraPino 4 ReservadoPino 5 ReservadoPino 6 0V (terra)Pino 7 CAN_HPino 8 ReservadoPino 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
Fonte: Autoria própria
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é oescalonamento
Fonte: Autoria própria
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 deamostragem
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𝑆𝑚
5
⌋︂+ 47 + 8𝑆𝑚)
)︂𝜏𝑏𝑖𝑡 (7)
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 bytesResolução: 0,5 rpm/bit, 0 offsetLargura de dados: 0 a 32, 127,5 rpmTipo: Medido
Informação adicional
PGN: 61473Fonte: 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 dedados 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 CANinserir 87C591.h1: Define a estrutura da mensagem CAN2: Inicia a porta RS2323: Define a transmissão via CAN4: Define a recepção via CAN5: 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 automotivode um modelo Golf
Fonte: (BAEKER, 2014)
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®
Fonte: Autoria própria
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
Delimitaro tema
Realizarpesquisa
bibliográfica
Levantar ashipóteses
para soluçãodo problema
Desenvolvera melhorsolução
encontrada
Testar ométodo
Escrever osresultados
obtidos
Fonte: Autoria própria
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
Fonte: Autoria própria
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
Fonte: Autoria própria
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
Fonte: Autoria própria
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
Fonte: Autoria própria
Na figura 30 mostra-se um exemplo de um bloco Function Call onde é escrita
uma mensagem CAN.
Figura 30 – Mensagem de Velocidade sendo escrita
Fonte: Autoria própria
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
Fonte: Autoria própria
Figura 32 – Distribuição dos instrumentos do painel
Fonte: Autoria própria
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
Fonte: Autoria própria
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 dedados
Fonte: Autoria própria
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
Fonte: Autoria própria
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
Fonte: Autoria própria
Figura 37 – Sinal da posição do pedal adquirido diretamente nos pi-nos do pedal
Fonte: Autoria própria
do painel do veículo, uma vez que o painel registra até 120 km/h.
Figura 38 – Gráficos no Simulink de saída
Fonte: Autoria própria
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
Fonte: Autoria própria
Figura 40 – Sinal visto pelo osciloscópio com valor igual a 100
Fonte: Autoria própria
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®
Fonte: Autoria própria
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
Fonte: Autoria própria
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
Fonte: Autoria própria
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
Número de Mensagens (em unidades) ×1040 0.5 1 1.5 2 2.5 3
Dife
ren
ça
en
tre
a e
ntr
eg
a d
e u
m f
ram
e e
ou
tro
(e
m m
s)
20
30
40
50
60
70
80
90
100
110
120
Diferença no Período de Recebimento da Mensagem VP2 X V
Fonte: Autoria própria
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 mensagemVP2_X_V
Número de Mensagens (em unidades)
7200 7400 7600 7800 8000 8200 8400
Difere
nça e
ntr
e a
entr
ega d
e u
m fra
me e
outr
o (
em
ms)
95
100
105
110
115
Diferença no Período de Recebimento da Mensagem VP2 X V
Fonte: Autoria própria
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
Fonte: Autoria própria
resultados dos gráficos obtidos nos aparelhos de medição.
59
REFERÊNCIAS
ARKESTEIJN, Vincent J.; KLUMPERINK, Eric A. M.; NAUTA, Bram. Jitterrequirements of the sampling clock in software radio receivers. IEEE TRANSACTIONSON CIRCUITS AND SYSTEMS, v. 53, n. 2, p. 90–94, fev. 2006. Citado 3 vezes naspáginas 30, 31 e 51.
BAEKER, Bernard. Automobil Electronics and Mechatronics. 2014. Vorlesung TUDresden. 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 componentcommunications in autosar. SAC ’17 Proceedings of the Symposium on AppliedComputing, Marraquexe, Morroco, p. 1473–1480, abr. 2017. Citado na página 15.
BORDOLOI, Unmesh D.; SAMII, Soheil. The frame packing problem for can-fd. IEEEReal-Time Systems Symposium (RTSS), n. 1, p. 284–293, fev. 2014. Citado napágina 15.
BROY, Manfred et al. What is the benefit of a model-based design of embeddedsoftware 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 vezesnas páginas 32 e 51.
ERKKINEN, Tom. Fixed-point ecu code optimization and verification with model-baseddesignt. 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 forbootstrapping 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ãoPaulo, 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 ofdistributed 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 incity-bus information integrated control system development. IEEE InternationalConference 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. Citadona página 15.
ISO17458. Road Vehicles: Communication on flexray. [S.l.], 2010. Citado na página15.
ISO/TC22/SC31. Road Vehicles: In-vehicle ethernet. [S.l.], 2010. Citado na página15.
JUNGER, Markus. Introduction to J1939: Version 1.1. [S.l.], 2010. Citado na página33.
KVASER. Kvaser Leaf Light HS v2. 2018. . Acessado: 24.05.2018. Citado na página 41.
LIU, H.; AN, J.-P.; YANG, J. Vehicle network communication protocol - a case ofstudy. n.d. Citado na página 22.
https://www.kvaser.com/product/kvaser-leaf-light-hs-v2/https://www.kvaser.com/product/kvaser-leaf-light-hs-v2/
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 UMABOX TRUCK PARA REALIZAÇÃO DE TESTES ELÉTRICOS EM COMPONENTESAUTOMOTIVOS. Curitiba, Brasil: [s.n.], 2013. Repositório UTFPR. Citado na página42.
MERCER MANAGEMENT CONSULTING; FRAUNHOFER GESELLSCHAFT.Future automotive industry structure (fast) 2015. In: MATERIALIEN ZURAUTOMOBILINDUSTRIE. Frankfurt, Alemanha, 2003. p. 32. Citado na página 14.
MOHR, D et al. The road to 2020 and beyond: What’s driving the globalautomotive industry? 2013. McKinsey & Company. Citado na página 14.
NASSIN, Bessaad. Controller Area Network (CAN bus) in the AutomotiveIndustry: An efficient way to establish in-system communication. 2016. Citado napágina 29.
NATALE, Marco Di; SILVA, Celso L. M. Da; SANTOS, Max M. D. On the applicabilityof 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 ofthe IEEE, IEEE, v. 93, n. 6, p. 1204–1223, maio 2005. ISSN 10.1109. Citado 2 vezesnas páginas 15 e 21.
NEME, João. H.; SANTOS, Max. M. D.; TEIXEIRA, Evandro L. S. Model based designfor automobile external lighting systems. 24th SAE Brasil International Congressand Display, São Paulo, Brasil, n. 1, p. 1–11, set. 2015. Citado 2 vezes nas páginas37 e 47.
PIZYBLSKI, Manoela G. ESTUDO DE FERRAMENTAS DE COMUNICAÇÃO DEDADOS PARA MEDIÇÃO, CALIBRAÇÃO E TESTES EM SISTEMAS VEICULARES.Ponta Grossa, Brasil: [s.n.], 2017. Repositório UTFPR. Citado 3 vezes nas páginas35, 50 e 53.
62
RBEBS LTDA. Busmaster Help: An228. [S.l.], 2011. Citado 2 vezes nas páginas 40e 53.
ROBERT BOSCH GMBH. CAN Specification: Version 2.0. [S.l.], 1991. Citado 2vezes nas páginas 15 e 23.
. CAN with Flexible Data-Rate Specification: Version 1.0. [S.l.], 2012. Citadona página 15.
SAE. Lin Network for Vehicle Applications Conformance Test. [S.l.], 2005. Citadona página 15.
. SAE J1939/71: Recommended practice of a serial control and communicationsvehicle 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 napágina 30.
SILVA, Celso L. M. et al. New approach of tools application for systems engineeringin 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étricautilizando a metodologia de projeto baseado em modelos. 2017. Dissertação(Mestrado) — Universidade de Brasília, Brasília, Brasil, 2017. Citado 2 vezes naspáginas 37 e 38.
SILVA, Rafael R. Da. Modelagem e análise de redes automotivas em ambientevirtual. 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 paraautomação e