BACHARELADO EM ENGENHARIA ELETRÔNICA
CELSO LUIZ MENDES DA SILVA
MODELAGEM E TESTE EM BANCADA DE UMA REDE DE
COMUNICAÇÃO NO PADRÃO SAE J1939
TRABALHO DE CONCLUSÃO DE CURSO
PONTA GROSSA 2018
MODELAGEM E TESTE EM BANCADA DE UMA REDE DE
COMUNICAÇÃO NO PADRÃO SAE J1939
Trabalho de Conclusão de Curso apresen-tado como requisito parcial à obtenção do título de Bacharel em Engenharia Ele-trônica, do Departamento de EleEle-trônica, da Universidade Tecnológica Federal do Paraná.
Orientador: Prof. Dr. Max Mauro Dias Santos
PONTA GROSSA 2018
Diretoria de Graduação e Educação Profissional Departamento de Eletrônica
Bacharelado em Engenharia Eletrônica
TERMO DE APROVAÇÃO
MODELAGEM E TESTE EM BANCADA DE UMA REDE DE COMUNICAÇÃO NO PADRÃO SAE J1939
por
CELSO LUIZ MENDES DA SILVA
Este Trabalho de Conclusão de Curso foi apresentado às 10:00 de 08 de junho de 2018 como requisito parcial para a obtenção do título de Bacharel em Engenharia Eletrônica. O candidato foi arguido pela Banca Examinadora composta pelos profes-sores abaixo citados. Após deliberação, a Banca Examinadora considerou o trabalho aprovado.
Prof. Dr. Max Mauro Dias Santos Orientador
Prof. Dr. Frederic Conrad Janzen Prof. Msc. Robson Moreira de Oliveira
Membro Titular Membro Titular
Prof. Dr. Josmar Ivanqui Prof. Msc. Jeferson José Gomes
Responsável pelos TCC Coordenador do Curso
inúmeras pessoas que tornaram o caminho até aqui possível.
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.
recue ante a nenhum pretexto, porque o mundo tentará te dissuadir (Nietzsche, Friedrich, 1885).
MENDES DA SILVA, Celso Luiz.MODELAGEM E TESTE EM BANCADA DE UMA REDE DE COMUNICAÇÃO NO PADRÃO SAE J1939. 2018. 66 f. Trabalho de
Conclusão de Curso (Bacharelado em Engenharia Eletrônica) – Universidade Tecnológica Federal do Paraná. Ponta Grossa, 2018.
A quantidade de componentes eletrônicos tem aumentado em automóveis ao longo dos anos. Quanto mais sistemas digitais em um veículo, maior a quantidade e a com-plexidade de dados que devem ser transmitidos entre as unidades de controle ele-trônico do automóvel e dispositivos externos. Assim, é necessário o uso de redes de comunicação automotiva para transmitir e gerenciar esses dados gerados. A rede CAN é uma das redes consagradas na indústria automotiva, porém o processo de desen-volvimento dessa rede, ainda hoje, é constante. Baseados nas redes CAN, surgem protocolos que especificam ainda mais elementos da comunicação de dados, como é o caso do SAE J1939. Por esse motivo, esse trabalho visa mostrar técnicas de desen-volvimento de uma rede CAN baseadas no protocolo SAE J1939 e mostrar a interação dessa rede com uma bancada com ECUs reais, sendo isso parte de um processo de desenvolvimento utilizado nas montadoras de veículos.
MENDES DA SILVA, Celso Luiz.MODELING AND TEST OF A COMMUNICATION NETWORK OF SAEJ1939 STANDARD IN A WORKBENCH. 2018. 66 p. Final
Coursework (Bachelor’s Degree in Electronic Engineering) – Federal University of Technology – Paraná. Ponta Grossa, 2018.
The number of electronic devices are increasing in the automobiles over the years. The more digital systems are part of a vehicle, the more complex data shall be transmitted between electronic control units of the vehicle themselves and also with external de-vices. Thus, it is necessary the use of automotive networks to transmit and manage the generated data from the vehicles. The Controller Area Network (CAN) is one of the established networks in the automotive industry, however its development process still remains nowadays. Based on the CAN emerge protocols that specify even more the data communication elements as the SAE J1939. For this reason, this work aims to show development techniques for CAN based on the SAE J1939 protocol and also show the interaction between this network with a workbench made by real ECUs, being this part of the development process used by the car manufactures.
Figura 1 – Mudança nas áreas de desenvolvimento de tecnologia na indústria
automotiva . . . 14
Figura 2 – Configuração básica de uma rede de comunicação . . . 19
Figura 3 – Comunicação de dois dispositivos segundo o padrão ISO/OSI . . . 20
Figura 4 – Redes em funcionamento em um veículo de classe média . . . 22
Figura 5 – Construção física da CAN . . . 23
Figura 6 – Modelo ISO/OSI para uma rede CAN . . . 24
Figura 7 – Diferenças de tensão entre os fios que geram bits no High-Speed CAN 25 Figura 8 – Como são gerados os níveis lógicos em uma rede CAN 2.0 . . . 26
Figura 9 – Diferenças de tensão entre os fios que geram bits no Low-Speed CAN 26 Figura 10 – Pinagem do conector DB-9 para acesso a rede . . . 26
Figura 11 – Divisão de uma mensagem CAN . . . 27
Figura 12 – Frame CAN 2.0A . . . 28
Figura 13 – Frame CAN 2.0B . . . 29
Figura 14 – Exemplo de três nós que disputam o barramento . . . 30
Figura 15 – Caminho seguido por um sinal desde a aquisição até o escalonamento 30 Figura 16 – Sinal analógico seno que deve passar pelo processo de amostragem 31 Figura 17 – Exemplo de um PGN . . . 34
Figura 18 – Tabelas usadas para o desenvolvimento do banco de dados de Hu et al. . . 35
Figura 19 – Desenvolvimento segundo o modelo V . . . 37
Figura 20 – Bancada para desenvolvimento de software automotivo de um mo-delo Golf . . . 38
Figura 21 – Interface do CANoe . . . 39
Figura 22 – Interface VN1610 . . . 40
Figura 23 – Tela inicial do BUSMASTER® . . . 41
Figura 24 – Kvaser Leaf Light v2 . . . 41
Figura 25 – Etapas do desenvolvimento do trabalho . . . 43
Figura 26 – Proposta de execução . . . 45
Figura 27 – Passos para criação do banco de dados - Parte I . . . 46
Figura 28 – Passos para criação do banco de dados - Parte II . . . 47
Figura 29 – Bloco de Simulink para Injetar Mensagens no Barramento . . . 47
Figura 30 – Mensagem de Velocidade sendo escrita . . . 47
Figura 31 – Bancada e materias utilizados nos testes . . . 48
Figura 32 – Distribuição dos instrumentos do painel . . . 48
Figura 33 – Mensagens lidas no barramento antes da associação de um dicio-nário de dados . . . 50
Figura 34 – Mensagens no barramento depois da utilização do dicionário de dados 50 Figura 35 – Sinais lidos no barramento . . . 51
Figura 36 – Sinal da posição do pedal aquirido através de uma mensagem CAN 52 Figura 37 – Sinal da posição do pedal adquirido diretamente nos pinos do pedal 52 Figura 38 – Gráficos no Simulink de saída . . . 52
Figura 39 – Sinal visto pelo osciloscópio com valor igual a 0 . . . 53
Figura 43 – Observação do Time Stamp da Mensagem VP2_X_V . . . 55 Figura 44 – Variação do atraso na entrega da mensagem VP2_X_V . . . 55 Figura 45 – Zoom de um período com muito jitter da mensagem VP2_X_V . . . 56 Figura 46 – Configuração para testes em trabalhos futuros . . . 58
Tabela 1 – Classes de redes automotivas . . . 22
Tabela 2 – Extensão vs Taxa de Transmissão no Barramento . . . 24
Tabela 3 – Pinos do conector DB-9 para uma rede CAN . . . 27
ABREVIATURAS
kbps Kilobits por segundo km/h Quilômetros por hora
m Metros
Mbps Megabits por segundo rpm Rotações por minuto
V Volts
SIGLAS
ACK Acknowledgement
CAN Controller Area Network
CAN-FD Controller Area Network with Flexible Data-Rate CRC Cyclic Redundancy Check
DLC Data Length Code
ECU Unidades de Controle Eletrônico, do inglês Electronic Control Units
EOF End of Frame
HIL Hardware-In-The-Loop
ID Identifier
IDE Identifier Extension
IP Instrument Panel
ISO International Organization for Standardization LIN Local Interconnect Network
MBD Model-based Design
MIL Model-In-The-Loop
OEM Original Equipment Manufacturer OSI Open Systems Interconnection
PGN Parameter Group Number
PIL Processor-In-The-Loop
RTR Remote Transmission Request
SAE Sociedade dos Engenheiros Automotivos, do inglês Society of Automo-tive Engineers
SIL Software-In-The-Loop
SOF Start of Frame
SPN Suspect Parameter Number WCBT Worst-case Blocking Time
ACRÔNIMOS
A/D Analógico-Digital
CAN_H CAN High
1 INTRODUÇÃO . . . . 14 1.1 TEMA . . . 16 1.2 PROBLEMA . . . 16 1.3 OBJETIVOS GERAIS . . . 16 1.4 OBJETIVOS ESPECÍFICOS . . . 16 1.5 JUSTIFICATIVA . . . 17 1.6 METODOLOGIA . . . 17 1.7 ORGANIZAÇÃO DO TRABALHO . . . 18 2 REVISÃO DA LITERATURA . . . . 19 2.1 REDES DE COMUNICAÇÃO . . . 19 2.2 REDES AUTOMOTIVAS . . . 21
2.3 O CONTROLLER AREA NETWORK (CAN) . . . 23
2.3.1 Camada Física . . . 24
2.3.2 Camada de Enlace . . . 27
2.3.2.1 Frame CAN . . . 27
2.3.2.2 Arbitragem de mensagens . . . 29
2.3.2.3 Requisitos temporais de uma rede CAN . . . 29
2.4 SAE J1939 . . . 33
2.5 DESENVOLVIMENTO DE UMDatabase . . . 35
2.6 DESENVOLVIMENTO DE UMA REDE CAN . . . 35
2.6.1 Desenvolvimento clássico . . . 36
2.6.2 Desenvolvimento baseado em modelos . . . 37
2.7 LEITURA DE DADOS NA REDE CAN: FERRAMENTAS MAIS UTILIZADAS . . . 39
2.7.1 CANoe e família Vector . . . 39
2.7.2 BUSMASTER® . . . 40
2.7.3 KVASER Leaf Light v2 . . . 41
2.8 ARQUITETURA DE ECUS NO CAMINHÃOVOLVO FH . . . 41
3 MATERIAIS E MÉTODOS . . . . 43
3.1 DELIMITAÇÃO DO TEMA . . . 44
3.2 PESQUISA BIBLIOGRÁFICA . . . 44
3.3 LEVANTAMENTO DE HIPÓTESES . . . 45
3.4 DESENVOLVIMENTO . . . 45
3.4.1 Criação do banco de dados . . . 46
3.4.2 Simulação CAN através do Matlab/Simulink . . . 46
3.5 TESTES E AQUISIÇÃO DE DADOS . . . 48
3.6 ESCRITA . . . 49
4 RESULTADOS E DISCUSSÃO . . . . 50
5 CONCLUSÕES E PERSPECTIVAS . . . . 57
REFERÊNCIAS . . . . 59
APÊNDICES 64
1 INTRODUÇÃO
A indústria automotiva está em constante desenvolvimento e as exigências dos clientes em relação as questões referentes ao desempenho, conforto e meio am-biente tem aumentado. Segundo Mohr et al (MOHR et al., 2013), as companhias do setor têm atualmente quatro grandes desafios para serem superados, que são: com-plexidade e custos, mercados divergentes, demanda digital e mudança do panorama da indústria. Em especial, a demanda digital está altamente relacionada com a tec-nologia embarcada nos veículos, uma vez que questões como conectividade, active safety e assistência ao motorista aparecem em foco.
Bäker (BAEKER, 2014) afirma ainda que nos últimos 20 anos a inovação na indústria automotiva têm se desenvolvido com foco nos produtos eletrônicos, princi-palmente nas classes mais luxuosas de automóveis. O gráfico da figura 1 foi adaptado de uma projeção feita pela empresa Mercer Management Consulting que na época já previa a crescente importância da eletrônica embarcada na indústria automotiva. É possível perceber no gráfico que componentes eletrônicos se tornam parte cada vez maior da composição de um automóvel.
Figura 1 – Mudança nas áreas de desenvolvimento de tecnologia na indústria automotiva
Fonte: Adaptado de (MERCER MANAGEMENT CONSULTING; FRAUNHOFER GESELLSCHAFT, 2003).
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.
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
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.
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 realireali-zaçã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.
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)
necessário que se estabeleçam regras de comunicação, assim surgem os padrões. Atualmente, os padrões mais utilizados são o Open Systems Interconnection (OSI) e o Internet. O modelo ISO/OSI, que é o padrão em que o CAN utiliza, é composto de sete camadas de comunicação, que são: Física, Enlace de Dados, Rede, Transporte, Sessão, Apresentação e Aplicação (SOUSA, 2002). A figura 3 mostra como acontece a comunicação entre dois dispositivos pelo modelo ISO/OSI.
Figura 3 – Comunicação de dois dispositivos segundo o padrão ISO/OSI
Fonte: (SOUSA, 2002)
Cada camada do modelo tem uma função que permite com que aconteça a comunicação. A seguir, descreve-se de maneira sucinta as funções de cada camada do modelo ISO/OSI:
Camada de aplicação
Camada mais alta do modelo. Segundo Silva (SILVA, 2015), é nessa camada que o usuário pode interagir com a rede requisitando serviços. O usuário pode ser humano ou software.
Camada de apresentação
Essa camada é que faz a transdução entre as requisições feitas na camada da aplicação e a rede em si. Basicamente, ela transforma uma informação obtida do usuário em um dado que será entendido pela rede. Nessa fase as informações como letras, números e símbolos serão convertidas em bits. Na camada de apresentação
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
em aplicações de Infotainment. Devido essa grande diversidade na utilização das re-des, elas são classificadas atualmente pela SAE (SILVA, 2015). A tabela 1 adaptada de Liu et al. (LIU; AN; YANG, n.d.) mostra a atual divisão de classes das redes auto-motivas. O CAN está inserido nas classes B e C.
Tabela 1 – Classes de redes automotivas
Classe Velocidade Aplicação
A < 10 kbps Funções não críticas. Por exemplo áudio B 10 kbps a 125 kbps Sensores, atuadores, painel, etc
C > 125 kbps Dados de tempo real
Fonte: (LIU; AN; YANG, n.d.)
Geralmente, automóveis apresentam mais de uma rede em funcionamento e a utilização destas se dá conforme a aplicação que se necessita. A figura 4 ilustra parte das redes que funcionam em um automóvel de classe média. Na figura é pos-sível observar que em um automóvel de classe média podem funcionar, ao mesmo tempo, uma rede High-Speed CAN, uma Low-Speed CAN, uma LIN, uma MOST e que todas elas se comunicam internamente e externamente através de gateways. O painel somente recebe as informações das redes CAN.
Figura 4 – Redes em funcionamento em um veículo de classe média
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
ISO 11898/2, que recebe o nome de High-Speed CAN. Além disso, existe a subdivi-são do High-Speed CAN em CAN 2.0A e CAN 2.0B, onde o primeiro diz respeito às mensagens com identificador de 11 bits e o segundo às mensagens com identificador estendido de 29 bits. O segundo foi desenvolvido para aplicações onde há um maior número de mensagens na rede.
Tabela 2 – Extensão vs Taxa de Transmissão no Barramento
Extensão do Fio(m) Taxa de Transmissão no Barramento (Mbps)
40 1,00 100 0,50 200 0,25 500 0,10 1000 0,05 Fonte: (CORRIGAN, 2008)
Com relação ao modelo OSI, o CAN utiliza, por padrão, duas camadas: a camada física e a camada de enlace. As demais camadas podem ser utilizadas pelos projetistas de rede, porém não são necessárias para o funcionamento da rede (SILVA, 2015). A figura 6 mostra como pode ser projetada uma rede CAN com base no modelo OSI. Segundo Corrigan (CORRIGAN, 2008), ela mostra que as funções da camada de aplicação podem ser implementadas por um desenvolvedor de software ou por um protocolo de alto nível, como por exemplo o CANopen, o DeviceNet e o SAEJ1939.
Figura 6 – Modelo ISO/OSI para uma rede CAN
Fonte: Adaptado de (CORRIGAN, 2008)
As divisões do protocolo conforme o modelo OSI estão elucidados nas subse-ções que seguem.
2.3.1 Camada Física
Como descrito anteriormente, na camada física de uma rede é onde são de-finidas as especificações mecânicas e elétricas, bem como procedimentos e funções
que os dispositivos desempenham para possibilitar a transmissão de dados.
Na rede CAN a transmissão acontece em um barramento com par de fios trançados que podem ser blindados ou não. Essa configuração é feita para que os níveis lógicos sejam obtidos através da diferença de tensão entre os condutores. Os fios recebem o nome de CAN High (CAN_H) e CAN Low (CAN_L).
Para o High-Speed CAN 2.0, os níveis de tensão que geram bits na rede estão apresentados na figura 7. Essa diferença entre níveis, gera tensões de 0 Volts (V) ou 2V, essa diferença será interpretada pelo controlador como um bit 0 ou 1 (0V é lido como um bit 1 e 2V é lido como um bit 0). No protocolo CAN o bit 1 é recessivo e o bit 0 é dominante. Essa diferença lógica está mostrada na figura 8, onde nota-se que os fio CAN_H e CAN_L quando conduzem 2,5 V cada, geram uma diferença de potêncial entre os dois fios de 0 V. Essa diferença é entendida no controlador CAN como um bit 1, que é recessivo. Por outro lado, quando CAN_H está em 3,5 V e CAN_L está em 1,5 V a diferença de potêncial entre os fios é de 2 V, o que é entendido no controlador CAN como um bit 0, que é dominante no protocolo.ele
Figura 7 – Diferenças de tensão entre os fios que geram bits no High-Speed CAN
Fonte: (GUIMARãES, 2007)
No Low-Speed CAN a diferença de tensão é dada como na figura 9. Observa-se aqui que ao contrário do High-Speed CAN, um bit recessivo não é produzido por uma diferença de potêncial igual a 0. O bit 1, recessivo, acontece quando a diferença de potêncial entre CAN_H e CAN_L é igual a 5 V, enquanto que uma diferença de 2,2 V produzirá um bit 0, dominante. A forma de obtenção de bits 0s e 1s é semelhante ao procedimento na figura 8.
Para acesso externo do barramento, a norma prevê que as interfaces de acesso à rede usem um conector DB-9 . A pinagem do conector está definida como na figura 10.
Figura 8 – Como são gerados os níveis lógicos em uma rede CAN 2.0
Fonte: (BAEKER, 2014)
Figura 9 – Diferenças de tensão entre os fios que geram bits no Low-Speed CAN
Fonte: Adaptado de (VECTOR, 2010)
Figura 10 – Pinagem do conector DB-9 para acesso a rede
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.
Tabela 3 – Pinos do conector DB-9 para uma rede CAN Pino 1 Reservado Pino 2 CAN_L Pino 3 Terra Pino 4 Reservado Pino 5 Reservado Pino 6 0V (terra) Pino 7 CAN_H Pino 8 Reservado
Pino 9 +V (alimentação opcional)
Fonte: Autoria Própria
2.3.2 Camada de Enlace
Na camada de enlace é onde acontece o escalonamento de sinais, o desen-capsulamento de sinais, a arbitragem de IDs, a detecção e a correção de erros. Essa camada é muito importante para o protocolo, pois é devido as funções dela que ele se torna confiável para utilização em aplicações de tempo real.
2.3.2.1 Frame CAN
Um frame CAN está dividido em três campos na camada de enlace, são eles: o campo de identificação ou Header, o campo de dados úteis ou de Payload e o campo de reconhecimento ou Trailer. A figura 11 mostra a função de cada um desses campos.
Figura 11 – Divisão de uma mensagem CAN
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.
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.
• 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
Figura 14 – Exemplo de três nós que disputam o barramento
Fonte: Adaptado de (SANTOS, 2014)
dois importantes processos: a conversão Analógico-Digital (A/D) e o escalonamento de sinais em mensagens. A figura 15 mostra os passos que acontecem desde a leitura de um sinal até o encapsulamento deste dentro de uma mensagem.
Figura 15 – Caminho seguido por um sinal desde a aquisição até o escalonamento
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)
𝑠𝜏(𝑘) = 𝑠(𝑘𝜏 + ∆𝑡(𝑘𝜏 )) ≈ 𝑠(𝑘𝜏 ) + ∆𝑡(𝑘𝜏 ).
𝜕𝑠(𝑡)
Figura 16 – Sinal analógico seno que deve passar pelo processo de amostragem
Fonte: (ARKESTEIJN; KLUMPERINK; NAUTA, 2006)
Onde s(t) é o sinal de entrada, 1/𝜏 é a taxa de amostragem, s(k𝜏 ) é o sinal amostrado e ∆t é o jitter de amostragem.
Entretanto, o atraso total da entrega da mensagem deve conter componentes de jitter da amostragem tanto quanto do tempo de encapsulamento, de tal maneira que o jitter total que influência o atraso total de entrega da mensagem é como mostrado na equação 3.
𝐽𝑡𝑜𝑡𝑎𝑙 = 𝐽𝑎𝑚𝑜𝑠𝑡𝑟𝑎𝑔𝑒𝑚+ 𝐽𝑒𝑠𝑐𝑎𝑙𝑜𝑛𝑎𝑚𝑒𝑛𝑡𝑜 (3)
O atraso de escalonamento de sinais em mensagens é dado como segue. O escalonamento de sinais em mensagens no CAN nada mais é do que pegar sinais digitalizados e colocá-los em frames CAN para que possam ser transmitidos. Cada sinal é mapeado dentro de uma mensagem CAN.
A rede CAN é de transmissão não-determinística, o que quer dizer que os frames CAN não trafegam de forma periódica. Para que um frame transmita são ne-cessários alguns passos, como:
1. Esperar que o algoritmo de escalonamento de sinais preencha um frame; 2. Entrar em uma fila de espera no controlador CAN, ou seja entrar em buffer ; 3. Se houver uma mensagem de menor prioridade que começa a transmissão antes
da entrada da mensagem em buffer, então esperar até que a mensagem de menor prioridade termine a transmissão;
4. Aguardar até que todas as mensagens em buffer com maior prioridade comple-tem transmissão.
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.
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.
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 rere-cebem um PGN. Um PGN pode conter vários SPNs. Ou seja, uma mensagem pode carregar vários sinais, conforme a capacidade de escalonamento da mensagem. Como exem-plo apresenta-se na tabela 4 um sinal contido na norma e na figura 17, uma mensagem que pode carregar diversos sinais. Ambos foram escolhidos aleatoriamente na norma.
Tabela 4 – Exemplo de um SPN
SPN 916 Engine Speed 2
Velocidade do motor medida pelo sensor 2
Tamanho do sinal: 2 bytes
Resolução: 0,5 rpm/bit, 0 offset
Largura de dados: 0 a 32, 127,5 rpm
Tipo: Medido
Informação adicional
PGN: 61473
Fonte: Adaptado de (SAE, 2005b)
Figura 17 – Exemplo de um PGN
Fonte: (SAE, 2005b)
É possível observar na figura 17 que o PGN recebe um PDU Format, um PDU Specific, um Data Page e um Extended Data Page. O PDU Format define se a mensagem é transmitida em modo ponto-a-ponto ou broadcast (PDU Format > 240, então transmissão broadcast). O PDU Specific define o endereço do grupo de ECUs ou da ECU específica que vai receber a mensagem.
2.5 DESENVOLVIMENTO DE UM DATABASE
Hu et al. (HU et al., 2007) elucidam em seu trabalho os passos básicos para a criação de um Database baseado no SAE J1939. Os autores usaram três tabelas de apoio para o desenvolvimento. Essas tabelas estão mostradas na figura 18.
Figura 18 – Tabelas usadas para o desenvolvimento do banco de dados de Hu et al.
Fonte: (HU et al., 2007)
Um processo similar também é feito por Pizyblski (PIZYBLSKI, 2017). O pri-meiro passo em ambos os trabalhos é definir quais sinais se deseja transmitir, depois procurar o respectivo SPN no documento SAE J1939/71. Através do SPN é possível encontrar em qual mensagem aquele sinal está contido. Isso é possível graças ao PGN da mensagem.
Uma vez que os sinais e as mensagens estão devidamente ordenados, o pró-ximo passo é olhar os valores de offset, data range, resolução, entre outros dados contidos no documento SAE J1939/71 e então usar um editor de banco de dados para criar as mensagens. Em Hu et al. os programas utilizados são o Delphi e o SQL Server2000, enquanto que Pizyblski utiliza o BUSMASTER®.
Através das tabelas na figura 18 é mais fácil organizar esse desenvolvimento.
2.6 DESENVOLVIMENTO DE UMA REDE CAN
Em relação ao desenvolvimento de redes CAN, pode-se dizer que há atual-mente duas principais abordagens: a abordagem clássica, com desenvolvimento em linguagem de alto nível, como C e C++, ou a abordagem de desenvolvimento baseado
em modelos. Para a primeira abordagem utiliza-se compiladores e software de desen-volvimento para microcontroladores como o MPLAB e o ARDUINO IDE, enquanto que a segunda abordagem é possível de ser feita em ambientes computacionais como o Matlab/Simulink®.
2.6.1 Desenvolvimento clássico
Souza (SOUZA, 2013) desenvolveu em seu trabalho a abordagem clássica utilizando controlador PIC18F4580, sendo o desenvolvimento feito com linguagem C. Guimarães (GUIMARãES, 2007) mostrou em seu trabalho um roteiro de implementa-ção de uma rede CAN sendo esse baseado no desenvolvimento clássico, assim como Souza.
Nos dois trabalhos os passos seguidos são semelhantes. Guimarães diz que a programação de uma rede CAN dentro de uma ECU está armazenada na memória RAM da mesma. Esse programa é que implementa rotinas essenciais para a comuni-cação na rede CAN. São essas rotinas:
• Inicialização da porta de comunicação CAN; • Rotina de transmissão e recepção via CAN; • Rotina de leitura de uma entrada digital; • Rotina de acionamento de uma saída digital.
Assim, o exemplo de código utilizado em Guimarães está esquematizado no algoritmo 1:
Algoritmo 1 – Algoritmo de desenvolvimento de uma rede CAN inserir 87C591.h
1: Define a estrutura da mensagem CAN 2: Inicia a porta RS232
3: Define a transmissão via CAN 4: Define a recepção via CAN 5: imprime Mensagem Fonte: (GUIMARãES, 2007)
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.
• SIL: pertencente a etapa de verificação e validação. Aqui controlador é
conver-tido em código fonte em linguagem C, por exemplo (SILVA, 2017).
• PIL: o código fonte gerado na etapa anterior, caso tenha passado nos testes, é
embarcado no controlador a ser utilizado. A Planta ainda permanece em forma de modelo.
• HIL: nessa etapa tanto controlador como planta estão embarcados. A planta
pode estar em um simulador ou ser real. Segundo Silva (SILVA, 2017), o objetivo do HIL é verificar a integração entre os sistemas de hardware e software.
Para a realização desse método, alguns programas de computador são muito importantes como é o caso do IBM DOORS para o gerenciamento de requisitos e o Matlab/Simulink® para o desenvolvimento de software propriamente dito. Por exem-plo, Erkkinen et al. (ERKKINEN et al., 2011), Erkkinen (ERKKINEN, 2009) e Franco (FRANCO et al., 2016) usam o Matlab/Simulink® em seus trabalhos de MBD.
A metodologia MBD é vantajosa em muitos sentidos às montadores de auto-móveis. Na figura 20 mostra-se uma bancada de desenvolvimento para um modelo GOLF da Volkswagen AG. Os testes de HIL, por exemplo, são todos realizados em uma bancada como na figura 20 antes de serem feitos em veículos reais.
Figura 20 – Bancada para desenvolvimento de software automotivo de um modelo Golf
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 comcom-putador 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)
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;
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,
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 propriedagran-des 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.
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
Delimitar o tema Realizar pesquisa bibliográfica Levantar as hipóteses para solução do problema Desenvolver a melhor solução encontrada Testar o método Escrever os resultados 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®.
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. Primeifo-ramente, 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.
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.
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
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
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:
• 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.
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 observa-seria possível trabalhar os dados sem houve uma "tradução" desta para algo do entendimento humano.
Figura 34 – Mensagens no barramento depois da utilização do dicionário de dados
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.
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
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
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
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.
repre-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) ×104
0 0.5 1 1.5 2 2.5 3
Diferença entre a entrega de um frame e outro (em ms)
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
cada 110 ms ou 90 ms.
Figura 45 – Zoom de um período com muito jitter da mensagem VP2_X_V
Número de Mensagens (em unidades)
7200 7400 7600 7800 8000 8200 8400
Diferença entre a entrega de um frame e outro (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.
