O que é barramento CAN (Controller Area Network) e como ele se compara a outras redes de barramento de veículos

O que é o protocolo CAN Bus?

O Controller Area Network - CAN bus é um protocolo baseado em mensagem projetado para permitir que as unidades de controle eletrônico (ECUs) encontradas nos automóveis de hoje, bem como outros dispositivos, se comuniquem entre si de maneira confiável e prioritária. Mensagens ou “frames” são recebidos por todos os dispositivos da rede, o que não requer um computador host. O CAN é suportado por um rico conjunto de padrões internacionais sob a ISO 11898.

O que é o CAN FD? 

CAN FD é uma versão de “(taxa de) dados flexíveis” do barramento CAN. O comprimento padrão de cada mensagem foi aumentado em 800% para 64 bytes, e a taxa máxima de dados também foi aumentada de 1 Mbps para 8 Mbps. A parte “flexível” se refere ao fato de que as ECUs podem alterar dinamicamente suas taxas de transmissão e selecionar tamanhos de mensagens maiores ou menores, com base em requisitos em tempo real.

Apesar de todos esses avanços, o CAN FD ainda é totalmente compatível com as versões anteriores do CAN 2.0 padrão. Hoje, o CAN FD é encontrado em veículos de alto desempenho, mas espera-se que ele migre em todos ou na maioria dos veículos eventualmente.

Este vídeo fornece excelentes informações básicas sobre barramentos de dados de veículos, incluindo CAN:

Vantagens do barramento CAN

O padrão de barramento CAN é amplamente aceito e é usado em praticamente todos os veículos e muitas máquinas. Isso se deve principalmente aos principais benefícios abaixo:

• Simples e de baixo custo: as ECUs se comunicam por meio de um único sistema CAN em vez de linhas de sinais analógicos complexos diretos - reduzindo erros, peso, fiação e custos. Os chipsets CAN estão prontamente disponíveis e acessíveis.

• Totalmente centralizado: o barramento CAN fornece um ponto de entrada para se comunicar com todas as ECUs da rede - permitindo diagnósticos centrais, registro de dados e configuração.

• Extremamente robusto: o sistema é robusto para perturbações elétricas e interferência eletromagnética - ideal para aplicações críticas de segurança (por exemplo, veículos)

• Eficiente: os frames CAN são priorizados por números de ID. Os dados de prioridade máxima obtêm acesso ao barramento imediato, sem causar a interrupção de outros frames.

• Peso do veículo reduzido: pela eliminação de quilômetros de fios elétricos fortemente isolados e seu peso do veículo.

• Fácil implantação: um padrão comprovado com um rico ecossistema de suporte.

• Resistente a EMI: isso torna o CAN ideal para aplicações críticas em veículos.

O CAN tem excelentes recursos de controle e detecção de falhas. A detecção de um erro é feita facilmente e, portanto, os dados transmitidos chegam onde precisam ir.

É um protocolo ideal quando o controle distribuído de um sistema complexo é necessário. Ele reduz a fiação pesada e, portanto, o custo e o peso. O custo dos chips é baixo e a implementação do CAN é relativamente fácil devido ao design limpo do protocolo.

Outra vantagem de usar o CAN é que as duas primeiras camadas: a camada física e a camada de enlace de dados, são implementadas em microchips de baixo custo, disponíveis em várias configurações.

Aplicações populares de barramento CAN

Hoje, as aplicações do CAN são dominadas pelo mundo automotivo e de veículos motorizados, mas não se limitam a isso. O CAN é encontrado em praticamente todos os setores. Você pode encontrar o protocolo CAN sendo usado em:

• Todo tipo de veículo: motocicletas, automóveis, caminhões ...

• Telemática da frota de serviço pesado

• Aviões

• Elevadores

• Instalações de manufatura de todos os tipos

• Navios

• Equipamento médico

• Sistemas de manutenção preditiva

• Máquinas de lavar, secadoras e outros aparelhos domésticos.

Uma breve história do CAN Bus

Quando você liga um interruptor em sua casa para acender as luzes, a eletricidade flui do interruptor para as luzes. Como resultado, os interruptores e a fiação precisam ser pesados e isolados o suficiente para lidar com a corrente máxima esperada. As paredes de sua casa são preenchidas com essa fiação pesada e isolada.

Carros e caminhões costumavam ser conectados exatamente da mesma maneira: desde que Henry Ford teve a ideia de adicionar luzes e uma buzina elétrica a seus carros em 1915, a eletricidade fluía da bateria por meio de interruptores para as luzes e outros dispositivos. Na década de 1960, havia milhares de fios pesados passando por todos os veículos. Cada pouco de peso extra reduz a eficiência de combustível de um veículo.

Após os embargos do petróleo da década de 1970, houve uma pressão crescente sobre os fabricantes de automóveis para melhorar sua eficiência de combustível. Então, eles começaram a procurar maneiras de reduzir o peso dos carros que estavam fabricando.

No início da década de 1980, os carros tinham cada vez mais ECUs (unidades de controle eletrônico) dentro deles, e empresas como a Robert Bosch, da Alemanha, estavam procurando um tipo de sistema de comunicação de barramento que pudesse ser usado como sistema de comunicação entre várias ECUs e sistemas veiculares . Eles pesquisaram o mercado, mas não conseguiram encontrar exatamente o que precisavam, então começaram a desenvolver a “Controller Area Network” em parceria com a fabricante de automóveis Mercedes-Benz e a fabricante de semicondutores Intel®, e várias universidades na Alemanha.

Em 1986, a Bosch introduziu o padrão CAN no Congresso SAE em Detroit. Um ano depois, a Intel Corporation iniciou as remessas dos primeiros chips controladores CAN, e o mundo automotivo mudou para sempre. Olhando para trás, a redução de peso que resultou do desenvolvimento do CAN foi quase um subproduto da sorte, mas muito real, no entanto.

Como o CAN Messaging funciona?

Dispositivos em um barramento CAN são chamados de "nós". Cada nó consiste em uma CPU, controlador CAN e um transceptor, que adapta os níveis de sinal dos dados enviados e recebidos pelo nó. Todos os nós podem enviar e receber dados, mas não ao mesmo tempo.

Os nós não podem enviar dados diretamente entre si. Em vez disso, eles enviam seus dados para a rede, onde ficam disponíveis para qualquer nó ao qual foram endereçados. O protocolo CAN é sem perdas, empregando um método de arbitragem bit a bit para resolver disputas no barramento.

Todos os nós são sincronizados de forma que todos eles amostrem dados na rede simultaneamente. Porém, os dados não são transmitidos com os dados do clock (hora), então o CAN não é verdadeiramente um barramento síncrono, como EtherCAT, por exemplo.

Com o CAN, todos os dados são enviados em frames, e existem quatro tipos:

• Os frames de dados transferem dados para um ou vários nós receptores

• Os frames remotos pedem dados de outros nós

• Erros de relatório de frames de erro

• Frames de sobrecarga relatam condições de sobrecarga

Existem duas variantes do comprimento da mensagem: padrão e estendida. A diferença real é o identificador adicional de 18 bits no campo de arbitragem.

Estrutura da Mensagem de Dados CAN (Frame CAN)

O campo de arbitragem contém o número de identificação da mensagem e o bit de solicitação de transmissão remota. As mensagens mais importantes têm números de ID mais baixos.

Se vários nós transmitem ao mesmo tempo, eles iniciam uma arbitragem simultânea. O nó com o menor número de ID de mensagem tem prioridade. Os bits dominantes sobrescrevem os bits recessivos no barramento CAN.

O identificador de mensagem pode ser de 11 bits (CAN padrão, 2.048 identificadores de mensagem diferentes) ou 29 bits de comprimento (CAN estendido, 537 milhões de identificadores de mensagem diferentes). O bit de solicitação de transmissão remota é dominante e indica que os dados estão sendo transmitidos.

Na maioria dos sistemas, o 1 lógico representa um nível alto e o 0 lógico representa um nível baixo. Mas é o contrário no barramento CAN. Portanto, os transceptores CAN normalmente usam um pull-up nas entradas do driver e nas saídas do receptor, de forma que os dispositivos tenham padronizado para um estado de barramento recessivo.

Variações do CAN Bus

O padrão ISO 11898 define várias versões do CAN. Os tipos dominantes de CAN usados na indústria automobilística são:

• Baixa velocidade CAN

• Alta velocidade CAN

• CAN FD (Taxa de dados flexível CAN)

Baixa velocidade CAN

Usado para sistemas tolerantes a falhas que não requerem altas taxas de atualização. A taxa máxima de transferência de dados é 125 kbps, mas a fiação é, portanto, mais econômica do que o CAN de alta velocidade. Em aplicações automotivas, o CAN de baixa velocidade é usado para diagnósticos, controles e visores do painel, vidros elétricos, etc.

Alta velocidade CAN

Usado para comunicações entre subsistemas críticos que requerem altas taxas de atualização e alta precisão de dados (por exemplo, sistema de frenagem antibloqueio, controle eletrônico de estabilidade, airbags, unidades de controle do motor, etc). As velocidades de transferência de dados do CAN de alta velocidade variam de 1 kbit a 1 Mbit por segundo.

O CAN de alta velocidade é mais rápido do que o de baixa velocidade, mas o requisito de largura de banda para novas aplicações automotivas está aumentando a cada ano, portanto, os OEMs de automóveis agora estão instalando o CAN FD em carros novos. CAN FD foi descrito ironicamente como "CAN com esteróides."

CAN FD (Taxa de dados flexível CAN)

A versão mais recente do CAN apresenta uma taxa de dados flexível, mais dados por mensagem e transmissões de velocidade muito mais alta. O comprimento dos dados dentro de cada mensagem CAN padrão (baixa velocidade e alta velocidade) é de 8 bytes, mas com CAN FD isso foi aumentado em 800% para 64 bytes de dados. Além disso, a taxa máxima de dados também aumentou drasticamente de 1 Mbps para 8 Mbps.

CAN FD também é compatível com versões anteriores e suporta o protocolo de comunicação CAN 2.0, bem como protocolos especiais como SAE J1939, onde a saída CAN é usada como somente leitura. O CAN FD é essencialmente uma extensão do padrão CAN original conforme especificado na ISO 11898-1 e é totalmente compatível com os sistemas CAN clássicos.

O CAN FD é um passo importante porque permite que as ECUs alterem dinamicamente suas taxas de transmissão e selecionem tamanhos de mensagens maiores ou menores, com base em requisitos em tempo real. Ele é encontrado agora em veículos de alto desempenho, mas conforme o desempenho do ECU aumenta e os custos de hardware do CAN FD caem, é apenas uma questão de tempo antes que o CAN FD faça seu caminho em praticamente todos os veículos.

Padrões e protocolos CAN adicionais

Por que precisamos de padrões e protocolos adicionais “além” do CAN? É simplesmente porque, embora CAN seja um protocolo elegante e confiável, isso é realmente tudo o que é. É um sistema de mensagens, mas não inclui nenhuma forma de analisar ou compreender os dados das mensagens. É por isso que várias empresas criaram padrões e protocolos adicionais que são executados dentro ou sobre o CAN, fornecendo funcionalidades adicionais. Os mais conhecidos incluem:

SAE J1939 em CAN

O protocolo SAE J1939 foi desenvolvido originalmente para ser usado por caminhões pesados e plataformas de trator-reboque nos EUA. Hoje é usado por fabricantes de motores diesel em todo o mundo. J1939 é um protocolo de nível superior executado na camada física CAN. Ele fornece algumas funções úteis específicas para caminhões pesados, como caminhões de 18 rodas.

O protocolo tem algumas restrições que foram colocadas intencionalmente para promover a maior confiabilidade possível, incluindo limitar o identificador de mensagem a 29 bits e limitar a velocidade do barramento a 250 ou 500 kbps.

O software DewesoftX permite que o engenheiro selecione a decodificação J1939 por meio de uma caixa de seleção na tela de configuração CAN para qualquer porta CAN disponível. Obviamente, isso pressupõe que as mensagens no barramento CAN sejam formatadas de acordo com o padrão J1939. As mensagens de dados têm o mesmo comprimento do padrão CAN estendido.

O campo de arbitragem contém uma fonte adicional e um endereço de destino, e a taxa de transmissão é limitada a 250 kbps ou 500 kbps, dependendo da versão do padrão J1939 que está sendo usada. J1939 é uma seleção na tela de configuração padrão do Dewesoft X CAN - nenhum hardware ou software adicional é necessário.

Saber mais:

• Configurando CAN, incluindo dados J1939, com DewesoftX

OBD II (também conhecido como “OBD 2”)

Esta porta de diagnóstico a bordo é encontrada em todos os carros fabricados desde 1989. Normalmente localizada a 2 pés (0,61 metros) do volante, é uma interface que permite que oficinas de conserto de automóveis, bem como proprietários de veículos, diagnostiquem problemas no veículo conectando um scanner ferramenta ao seu conector de 16 pinos. (Fotografado aqui sob o volante do Toyota 4Runner 2016).

As ferramentas de digitalização podem ler o DTC (códigos de problemas de diagnóstico) relatados pelo veículo. A interface OBD II é necessária para transportar dezenas de canais de dados em tempo real, como RPM, velocidade do veículo, temperatura do resfriador e muito mais. As interfaces CAN Dewesoft podem ser conectadas a este conector OBD II conforme mostrado abaixo e podem ler, exibir e gravar qualquer um ou todos esses canais em sincronia com os outros dados sendo gravados.

A decodificação, exibição e gravação de mensagens ODB II em sistemas Dewesoft requerem um plug-in de software ODB II adicional. Você pode escanear DTC (códigos de problemas de diagnóstico) e muito mais com este sistema.

Saber mais:

• OBD II no software Dewesoft

XCP / CCP em CAN e Ethernet

O Protocolo Universal de Medição e Calibração (XCP) foi projetado para conectar ECUs a sistemas de calibração. O “universal” em seu nome se refere ao fato de que ele pode ser executado em cima do barramento CAN, CAN FD, FlexRay, Ethernet e muito mais. É o sucessor do protocolo de calibração CAN (CCP) original desenvolvido na década de 1990.

A Dewesoft suporta os protocolos XCP / CCP através dos plug-ins XCP / CCP Master e XCP / CCP Slave que são executados no software DewesoftX DAQ. O hardware de interface Dewesoft CAN (e ethernet) padrão pode ser usado.

Além desses plug-ins XCP Slave e Master, os sistemas de aquisição de dados SIRIUS XHS e IOLITE LX da Dewesoft podem servir dados nativamente via XCP na Ethernet sem a necessidade de qualquer software adicional. Assista a este breve vídeo introdutório para obter mais informações sobre Dewesoft XCP Data Acquisition Systems e XCP Data Loggers:

Saber mais:

• XCP Slave DewesoftX Manual

• Manual XCP Master DewesoftX

CANopen

CANopen é um protocolo de camada superior usado para aplicações de controle embarcado. Por ser baseado no protocolo de mensagens CAN, os sistemas DAQ e data loggers que podem ler e gravar dados CAN também podem acessar dados do CANopen.

CANopen foi inventado para fornecer interoperabilidade fácil entre dispositivos em sistemas de controle de movimento. A comunicação entre os dispositivos é implementada em alto nível e a configuração do dispositivo também é suportada. É muito usado em aplicações de controle de movimento, robótica e controle de motor.

O CANopen é administrado pela organização internacional CAN in Automation - CiA. Estabelecido na Alemanha em 1992, CiA é um grupo internacional de usuários / fabricantes sem fins lucrativos para CAN. Eles se orgulham de ser uma plataforma imparcial para o desenvolvimento do protocolo CAN e para promover a imagem da tecnologia CAN.

CANopen fornece vários conceitos adicionais, incluindo:

Três modelos básicos de comunicação

• Master / Slave - onde um nó é o “master” e todos os outros são slave.

• Cliente / Servidor - algo semelhante a master / slave, exceto que os nós são servidores de dados solicitados a um nó cliente.

• Produtor / Consumidor - onde certos nós são configurados para produzir certos tipos de dados automaticamente, enquanto outros nós são configurados para consumi-los.

Dois protocolos de comunicação básicos

• SDOs para configuração de nós

• PDOs para envio de dados em tempo real

Perfis de dispositivo

• Módulos de entrada / saída CiA 401

• Controle de movimento CiA 402 para independência do fornecedor

Dicionário de Objetos

Existe um OD (Dicionário de Objetos) para cada dispositivo na rede. O OD possui uma configuração padrão para os dados que define a configuração de cada dispositivo da rede.

Estados do dispositivo

Um nó mestre é capaz de alterar ou redefinir o estado dos dispositivos na rede.

Folhas de dados eletrônicos (EDS)

O EDS é um formato de arquivo padrão para entradas OD - permitindo, por exemplo, ferramentas de serviço para atualizar dispositivos

Barramentos de comunicação relacionados

Além do CAN e dos protocolos executados nele descritos nas seções anteriores, existem outros barramentos de comunicação que são usados para aplicações em veículos:

• MOST (Transporte de Sistemas Orientado à Mídia)

• Ethernet Automotiva

• SENT SAE-J2716

• FlexRAY

• LIN Bus - Rede de interconexão local

Os veículos modernos de hoje usam uma combinação de vários barramentos de dados. Vamos dar uma olhada em cada um deles e ver como eles se comparam a um barramento CAN.

MOST (Transporte de Sistemas Orientado à Mídia)

Todos esperam que seu novo carro tenha um sistema de entretenimento melhor e mais capaz do que o carro anterior. O antiquado rádio AM / FM, padrão por mais de 50 anos, foi transformado para aceitar mídias removíveis, desde os velhos tempos das fitas cassete e de 8 trilhas até discos compactos (CD) e mídia flash removível. Hoje, o foco está em streaming de conteúdo de dispositivos móveis, bem como rádio por satélite (SIRIUS / XM® na América do Norte).

O Transporte de Sistemas Orientado à Mídia (MOST) é um barramento padrão usado para interconectar o entretenimento do veículo e os sistemas de informação desenvolvidos por uma parceria de fabricantes de automóveis chamada MOST Cooperation. Ele oferece taxas de dados de 25, 50 e 150 Mb / s. Mas deve-se observar que essas são taxas agregadas que são divididas entre todos os nós do barramento.

MOST é usada em quase todas as marcas de automóveis em todo o mundo. Até 64 dispositivos podem ser conectados a uma rede de anel MOST, o que permite que os dispositivos sejam conectados ou desconectados facilmente. Outras topologias também são possíveis, incluindo estrelas virtuais. Existem várias versões do MOST, incluindo:

• MOST25 oferece uma taxa de streaming máxima de 23 MB, que é realmente limitada a cerca de 10 kB / s devido à sobrecarga do protocolo e outras limitações.

• MOST50 dobra a largura de banda de MOST25.

• MOST150 triplica a largura de banda de MOST50 e adiciona uma camada física que permite a adição de ethernet.

MOST está enfrentando uma concorrência crescente da Ethernet Automotiva, que é discutida abaixo.

Ethernet automotiva

Novas tecnologias, como a assistência ao motorista e até as funcionalidades do veículo autodirigido / autônomo, exigem cada vez mais largura de banda para funcionar. Essa necessidade de velocidade, juntamente com o baixo custo do hardware Ethernet, tem sido um grande fator na promoção da Ethernet Automotiva entre as montadoras. Outras motivações para a ethernet automotiva incluem as taxas de transferência necessárias para LIDAR e outros sensores, dados brutos de câmeras, dados de GPS, dados de mapas e telas planas de resolução cada vez mais alta.

Mas, ao contrário de nossos ambientes confortáveis ​​de casa e escritório, um veículo está sujeito a uma gama muito mais ampla de temperaturas, choques e vibrações contínuas. Além disso, há EMI e RFI que devem ser bloqueados para que os dados críticos não sejam interferidos, especialmente aqueles relacionados à assistência ao motorista e prevenção de colisões.

O termo “Ethernet Automotivo” não se refere a um padrão específico por definição. Inclui qualquer rede baseada em Ethernet usada em veículos. Também se refere ao padrão OPEN Alliance BroadR-Reach desenvolvido pela Broadcom e ao IEEE 802.3bw-2015, também conhecido como 100Base-T1.

Apesar de suas vantagens óbvias de velocidade e popularidade mundial, até os últimos anos a ethernet era usada apenas para aplicações de diagnóstico em carros - em outras palavras, quando o carro estava em serviço e parado. Por quê? Devido à sua suscetibilidade a EMI (interferência eletromagnética) e RFI (interferência de radiofrequência), falta de sincronização de tempo determinística inerente e suscetibilidade a falha do conector devido à vibração. Os conectores CAT5 padrão, por exemplo, não sobrevivem em automóveis sob uso normal.

No entanto, esses problemas estão sendo tratados pelos grupos de trabalho IEEE 802.3 e 802.1. Nesse ínterim, a fabricante de chips Broadcom desenvolveu o BroadR-Reach ™, que adapta a tecnologia Ethernet para uso automotivo. O BroadR-Reach fornece velocidade de 100 Mb / s usando cabeamento de par trançado sem blindagem de até 15 metros ou de até 40 metros quando uma blindagem é adicionada aos cabos.

O BroadR-Reach foi adotado por alguns fabricantes de automóveis para sistemas de infoentretenimento, assistência ao motorista, diagnósticos a bordo e até mesmo aplicativos ADAS. Ele oferece taxas de dados de 100 Mbps por porta, que é muito maior do que a taxa agregada de 150 Mbps da MOST, por exemplo.

O padrão BroadR-Reach é supervisionado pela OPEN (One-Pair Ether-Net) Alliance, que defende a adoção da Ethernet automotiva.

Ethernet AVB (Audio Video Bridging) é o padrão IEEE AVB1.0. Ele está avançando em direção à aceitação para uso com câmeras e sistemas multimídia. AVB2.0 é voltado para aplicativos de controle de veículos. AVB é promovido pela AVnu Alliance.

Ethernet TSN (Time-Sensitive Networking) é o padrão IEEE 802.1 projetado para permitir mensagens determinísticas em Ethernet padrão. Não é um protocolo por definição, o TSN é um padrão implementado na camada 2 do Ethernet OSI - ou seja, a camada de dados (AVB também é um padrão da camada 2).

Como uma extensão do AVB Ethernet descrito acima, o TSN se concentra no tipo de sincronização de tempo, programação e formatação de pacotes que são necessários para aplicativos de veículos autônomos. Como o TSN tem tudo a ver com “tempo”, os protocolos de tempo de precisão (PTP) IEEE 802.1AS e IEEE 802.1ASRev foram selecionados para fornecer um conceito compartilhado de tempo entre os dispositivos.

Saber mais:

• Automotive Ethernet OPEN Alliance

• Padrões IEEE TSN / AVB

• BroadR-ReachEthernet TSN (inclui AVB)

De acordo com o Gartner, em 2017 havia um total de 19,3 milhões de portas Ethernet instaladas em veículos de consumo. Em 2020, esse número aumentou para 122,8 milhões, um número que deverá dobrar até 2023.

SENT SAE-J2716

SENT SAE-J2716 (t(Single Edge Nibble Transmission) foi projetado para ser uma alternativa de protocolo de baixo custo para CAN ou LIN. É um protocolo de transmissão unilateral que permite que os sensores enviem seus dados para ECUs.

Os dados são codificados usando modulação por código de pulso (PCM) e transmitidos em um único fio. Existem três fios no total: sinal, aterramento e alimentação. Os dados são codificados em "nibbles" de 4 bits.

Uma mensagem SENT típica tem 32 bits (8 nibbles), composta por:

• Dados de sinal: 24 bits (6 nibbles)

• Detecção de erro CRC: 4 bits (1 nibble)

• Informações de status: 4 bits (1 nibble)

Também é possível configurar mensagens de 20 bits (5 nibbles), onde os dados são de apenas 12 bits (3 nibbles).

Devido ao seu design de dados modulado, SENT é ideal para uso em ambientes com ruído elétrico.

Os sistemas Dewesoft suportam dados SENT SAE-J2716 usando canais de contador para ler um sinal SENT que está sendo transmitido por um sensor. Dois canais rápidos e qualquer número de canais lentos, que podem ser detectados automaticamente. Os engenheiros podem decodificar sinais SENT de vários sensores simultaneamente, onde cada sensor está usando um contador diferente, adicionando várias janelas de módulo. Os canais SENT estão disponíveis como canais Dewesoft.

Saber mais:

• SENT canais no software DewesoftX

FlexRAY

FlexRAY é um protocolo usado para aplicações automotivas dinâmicas, como controle de chassi. Foi criado em 2005 pelo Consórcio FlexRAY, mas desde então foi padronizado sob ISO 17458-1 a 17458-5.

FlexRAY transmite dados por meio de um ou dois cabos de par trançado sem blindagem. Ele roda a 10 Mbps e oferece suporte a configurações de um ou dois fios. Topologias de rede em barramento, estrela e híbrida são suportadas, em velocidades de até 10 Mbps. A sinalização diferencial mantém o ruído baixo sem a necessidade de cabos blindados, o que adiciona custo e peso.

Assim como no CAN, apenas um nó pode gravar em um barramento FlexRAY ao mesmo tempo. O CAN usa um bit de arbitragem para determinar quais dados têm prioridade e podem prosseguir. O FlexRAY, por outro lado, usa um método de Acesso Múltiplo por Divisão de Tempo (TDMA) em que cada nó sincronizado com o tempo deve aguardar sua vez para enviar uma mensagem. Isso evita colisões e permite maior rendimento geral de dados no barramento devido à alta taxa geral de dados do barramento.

FlexRAY é frequentemente implementado na topologia multiponto clássica compartilhada por LIN e CAN, no entanto, ele também pode ser configurado em uma topologia em estrela. A topologia em estrela tem a vantagem de não permitir que uma falha na fiação afete mais de um nó. FlexRAY também pode ser implementado em uma topologia mista, conforme mostrado abaixo.

FlexRAY é usado com mais frequência para powertrain de alto desempenho, segurança e aplicações de controle ativo do chassi. FlexRAY é mais caro do que uma implementação de barramento CAN.

No entanto, quando pares duplos de linhas de dados paralelas são usados, isso fornece redundância: quando uma linha é danificada, a segunda linha pode assumir o controle. Isso é importante em aplicações de missão crítica, como direção e frenagem. Os aplicativos FlexRAY que não são de missão crítica normalmente usam um único par trançado.

Os sistemas Dewesoft podem facilmente adquirir dados FlexRAY usando a opção de importação de biblioteca FIBEX. Um plugin de software está disponível para suportar todas as placas de interface Vector FlexRay.

Barramento LIN - Local Interconnect Network

LIN bus é uma alternativa econômica ao barramento CAN. É muito simples, mas necessariamente limitado a um nó mastere 15 nós slave. LIN é um sistema de mensagens serial unidirecional, onde os slaves ouvem os identificadores de mensagens endereçados a eles.

Por causa de sua largura de banda mais baixa e limitações de contagem de nós, o LIN é normalmente usado para controlar pequenos motores elétricos e controles. LIN é limitada a uma taxa de dados de 19,2 kbps ou 20 kbps.

LIN é uma rede de fio único definida pela ISO 9141. É usada para aplicações de baixa largura de banda, como vidros elétricos, luzes, fechaduras de portas, sistemas de entrada com cartão, espelhos elétricos, bancos elétricos e semelhantes.

O plugin de bus LIN para DewesoftX permite que os engenheiros se conectem e ouçam a comunicação em várias redes LIN. Usando o hardware LIN BUS da marca Vector, ele imita os slaves ouvintes que ouvem todas as transmissões de dados no barramento. A decodificação pode ser feita de três formas diferentes:

• Dados analógicos com amplas opções de escala

• Dados discretos

• Uma mistura de ambos

O plugin suporta a importação da configuração de arquivos de descrição LIN (LDF). Para ler o barramento LIN, é necessária uma placa Vector LIN BUS.

Comparando CAN com outros barramentos de veículos

Notas: * UTP = par trançado não blindado

Como ocorre com qualquer sistema de rede e interoperável, a escolha do barramento automotivo é mais bem orientada pelos requisitos da aplicação, ao mesmo tempo em que fica atento aos custos e aos requisitos e tendências projetados da indústria. Claramente, as montadoras não querem implementar barramentos antigos em novos designs, quando há barramentos melhores disponíveis a um custo de implantação equivalente ou melhor.

Sistemas DAQ Dewesoft CAN Bus

As interfaces de barramento CAN fornecidas como padrão ou opcional com os sistemas Dewesoft fornecem um alto nível de capacidade, bem como extensibilidade para protocolos adicionais.

Todas as interfaces CAN Dewesoft são isoladas galvanicamente, protegendo o instrumento e os dispositivos conectados de loops de aterramento e outros distúrbios elétricos. Todas as interfaces Dewesoft CAN utilizam o padrão CAN 2.0b de alta velocidade. A Dewesoft também oferece um dispositivo CAN FD.

Todas as interfaces CAN da Dewesoft podem ler e escrever mensagens CAN, permitindo que os engenheiros coloquem mensagens no barramento para solicitar dados de dispositivos CAN na rede e muito mais.

Toda a interface Dewesoft CAN pode ser configurada em segundos, porque o software de aquisição de dados DewesoftX incluso pode importar arquivos DBC. Os arquivos DBC são um formato padrão que permite aos engenheiros analisar o fluxo de dados em canais individuais com nomes, escala, unidades de engenharia adequadas e muito mais.

Clicar no botão "Configurar" na extremidade direita de qualquer linha de mensagem abre a tela de configuração do canal CAN mostrada abaixo:

DewesoftX torna extremamente fácil configurar canais CAN. O software pode importar e exportar arquivos CAN DBC ou XML. Os arquivos DBC são arquivos comuns para mensagem CAN e definição de canal. Após a importação, o software configurará automaticamente todos os canais CAN disponíveis e decodificará as mensagens CAN.

Recursos do software DewesoftX CAN

• Gravação, armazenamento e análise avançada do CAN

• Monitoramento e decodificação on-line de mensagens CAN

• Decodificação de mensagem CAN off-line

• Exibição visual para exibir dados CAN

• Análise matemática online e offline de canais CAN

• Importação e exportação de arquivos CAN DBC

• OBDII em CAN, J1939 e suporte XCP / CCP

• Tansmitir funcionalidade CAN

Interfaces Dewesoft CAN Bus

Dewesoft foi um dos primeiros fabricantes de sistema DAQ a implementar totalmente interfaces de barramento CAN com seu sistema de aquisição de dados analógico. Quase todo sistema Dewesoft DAQ tem pelo menos uma interface de barramento CAN embutida como padrão, e uma interface CAN dedicada adicional pode ser adicionada internamente, externamente ou ambos, mantendo a sincronização perfeita.

Já em 2008, o DEWE-43 original foi lançado, apresentando duas interfaces de barramento CAN de alta velocidade como um recurso padrão. Uma coisa muito importante saber é que os dados CAN que chegam a essas portas são totalmente sincronizados por hardware com os dados analógicos, bem como com os dados do contador / entrada digital. A interface CAN Dewesoft também é isolada galvanicamente, protegendo o instrumento e o próprio barramento de loops de aterramento e outros problemas elétricos.

Menos de um ano após seu lançamento, o DEWE-43 foi premiado como o Produto do Ano da NASA TECH BRIEFS Reader’s Choice por suas inovações em combinar poder DAQ e capacidade em um instrumento incrivelmente pequeno.

Hoje, Dewesoft oferece suporte para várias interfaces automotivas padrão para analisar e inspecionar dados de barramentos de veículos. Os dados podem ser capturados de todas as interfaces com suporte e sincronizados com outras fontes, como analógico, vídeo e outros.

Sistemas Dewesoft DAQ com interfaces CAN integradas

Conforme mencionado antes, quase todo sistema Dewesoft DAQ tem pelo menos uma porta CAN embutida como padrão, e todos os sistemas podem ser equipados com CAN se não for padrão, de acordo com esta tabela:

Interfaces CAN externas e sincronizáveis

Além da (s) porta (s) CAN incorporada (s) em quase todos os sistemas Dewesoft DAQ, interfaces CAN sincronizáveis separadas de 2, 4 e 8 portas estão disponíveis. Eles se conectam a um computador Windows executando o software Dewesoft X ou a um sistema Dewesoft DAQ via USB e um cabo de sincronização.

Módulo KRYPTONi-1xCAN-FD

O mais recente membro da família Dewesoft CAN bus é o KRYPTONi-1xCAN-FD. Este é um dispositivo CAN FD de porta única que se conecta ao sistema DAQ via EtherCAT®. Suporta taxas de dados CAN de alta velocidade de até 8 Mbps. Além disso, o CAN FD suporta o protocolo de comunicação CAN 2.0, bem como protocolos especiais como o J1939.

KRYPTONi-1xCAN-FD tem linhas de comunicação isoladas galvanicamente e uma fonte de sensor isolada de +5 V e +12 V. O limite de energia da fonte de sensor é 1,4 watts.

Como este módulo é membro da premiada linha de produtos KRYPTON ONE, ele pode suportar condições ambientais extremas, como uma faixa de temperatura operacional de -40 ° C e +85 ° C (-40 a + 185 ° F), e vedado contra poeira e líquidos de acordo com IP67.

KRYPTONi-1xCAN-FD é fornecido em um chassi KRYPTON ONE padrão com um conector de entrada DSUB9.