MODELAGEM E TESTE EM BANCADA DE UMA REDE...

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


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


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


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


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


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


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

Delimitaro tema

Realizarpesquisa

bibliográfica

Levantar ashipóteses

para soluçãodo problema

Desenvolvera melhorsolução

encontrada

Testar ométodo

Escrever osresultados

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 dedados


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

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


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


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

MODELAGEM E TESTE EM BANCADA DE UMA REDE...

Documents

Transcript of MODELAGEM E TESTE EM BANCADA DE UMA REDE...