> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/pt-br/vehicle-telematics-technology/can-and-obdii/intra-vehicle-communication-can-flexray-and-most.md). # Comunicação intra-veicular: CAN, FlexRay e MOST Redes veiculares usam CAN, FlexRay, MOST e Ethernet para comunicação entre ECUs. Cada protocolo atende a diferentes necessidades de velocidade, confiabilidade e largura de banda. CAN, FlexRay e MOST são todos protocolos de comunicação automotiva usados para conectar unidades de controle eletrônico (ECUs), unidades de controle da transmissão (TCUs) e módulos de controle da carroceria (BCMs) em veículos: * **CAN**\ Um protocolo baseado em mensagens que foi originalmente projetado para economizar cobre multiplexando a fiação elétrica em carros. O CAN tem uma largura de banda de cerca de 125 kpbs. * **FlexRay**\ Um protocolo de comunicação serial de alta velocidade, tolerante a falhas e determinístico que pode transferir dados a velocidades de até 10 Mbits por segundo por meio de dois fios trançados. O FlexRay é frequentemente usado em aplicações críticas de segurança, como módulos do trem de força. As cargas úteis do FlexRay, ou quadros de dados, podem ter até 127 palavras (254 bytes) de comprimento, o que é mais de 30 vezes mais longo do que as cargas úteis do CAN. * **MOST**\ Um padrão de barramento para redes multimídia veiculares que permite a transferência de áudio, vídeo e dados de alta qualidade. O MOST está disponível em três velocidades de transmissão: MOST25, MOST50 e MOST150. O CAN (Controller Area Network) é atualmente a rede embarcada em veículos mais amplamente usada. No entanto, com o desenvolvimento contínuo de veículos autônomos e tecnologia relacionada, há uma alta demanda por maior largura de banda e conectividade. Neste documento, descrevemos brevemente o CAN e outras opções de conectividade veicular, incluindo CAN sem fio, MOST, FlexRay e Ethernet automotiva. ## Barramento CAN: alguns princípios por trás Em sentido amplo, o barramento CAN (Controller Area Network-bus) é, na verdade, um conjunto de normas que permite que diferentes dispositivos se comuniquem entre si. É um sistema de barramento serial assíncrono (deslocado no tempo), desenvolvido em 1983 pela Robert Bosch GmbH com o objetivo de interconectar unidades de controle eletrônico (ECU) em veículos automotores. O CAN foi dividido em várias camadas, seguindo o modelo ISO/OSI, para alcançar flexibilidade e transparência de projeto. Para a comunicação na prática, o barramento CAN usa dois fios dedicados: CAN low e CAN high, por meio dos quais o controlador CAN é conectado a todos os componentes da rede. O CAN permite substituir uma fiação bastante complexa por um barramento de dois fios. O CAN usa um sinal diferencial, que o torna mais resistente a ruídos, com dois estados lógicos: recessivo e dominante. Atualmente, o barramento CAN é usado praticamente em tudo, de máquinas de café até [Gestão de Frotas](https://www.navixy.com/fleet-management/features/) e aplicações espaciais. Descrevemos brevemente mais adiante os princípios de funcionamento do barramento CAN. O protocolo de comunicações CAN ISO-11898:2003 explica como as informações são transmitidas entre dispositivos em uma rede com base em um modelo de Interconexão de Sistemas Abertos (OSI) que é apresentado como um conjunto de camadas em uma figura abaixo. As duas camadas mais baixas do modelo OSI/ISO de sete camadas são as camadas física e de enlace de dados. A camada física define a comunicação entre dispositivos conectados pelo meio físico. ![CAN e alternativas](https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-d50f3bc11d78b83e05bfefe9d3ac7d582dec1855%2Fcan-bus-principles-1.jpg?alt=media) A camada de enlace de dados, entre outras coisas, também cuida de organizar bits em quadros e inclui dois protocolos: CAN clássico (primeiro uso datado de 1988) e CAN FD (lançado em 2012). A camada de aplicação é essencialmente uma camada do usuário final e fornece acesso aos recursos da rede. Existem dois tipos de formatos de mensagem/quadro: padrão e estendido. Eles diferem entre si apenas pelo comprimento do identificador – o padrão tem 11 bits, enquanto o estendido tem 29 bits. Uma estrutura padrão de mensagem pode ser dividida em 8 partes, como mostrado na figura abaixo. Essas partes são: Start of Frame (SOF - o início da transmissão do quadro), CAN-ID (identificador do quadro, identificação da prioridade da mensagem), Remote Transmission Request (RTR, indica se um nó solicita dados de outro nó ou envia dados), Control (informa o tamanho dos dados em bytes), Data (valores reais dos dados que precisam ser escalados/convertidos), The Cyclic Redundancy Check (CRC, garantindo a integridade dos dados), ACK (acknowledge, indica se os dados estão sendo recebidos corretamente) e EOF (End of Frame), que marca o fim da mensagem/quadro CAN. ![CAN e alternativas](https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-eba86e7aeb438081d966dd3c6b187558c624ddfd%2Fcan-bus-principles-2.png?alt=media) A polaridade oposta da entrada e da saída do circuito de acionamento no barramento deve ser levada em conta. A figura acima demonstra um diagrama simplificado de entrada e saída de um transceptor CAN: fluxo de bits indo para/de um controlador CAN e/ou microcontrolador. Quando o controlador envia um fluxo de bits, estes são complementados e colocados na linha CANH. A linha CANL é sempre o complemento de CANH. O CAN deve monitorar tanto o que está atualmente no barramento quanto o que está enviando. Em aplicações, ambas as extremidades do barramento CAN devem ser terminadas, já que qualquer nó no barramento pode transmitir dados. Cada extremidade do enlace tem um resistor de terminação igual à impedância característica do cabo. Normalmente, o valor recomendado para os resistores de terminação é 120 Ω (em uma faixa de 100 Ω - 130 Ω). Não deve haver mais de dois resistores de terminação na rede, já que terminações adicionais colocam carga extra nos circuitos de acionamento. A imagem abaixo mostra um barramento de teste CAN. Os nós poderiam representar o envio de mensagens a partir de tecnologia de sensoriamento inteligente e de um controlador de motor. Uma aplicação típica poderia ser um sensor de temperatura. ![CAN e alternativas](https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-a5cb2689542e48625d481f44b3a3939a738f7b8f%2Fcan-bus-principles-3.png?alt=media) Se outro nó de sensor precisar enviar uma mensagem simultaneamente, a arbitragem garante que a mensagem seja enviada. Por exemplo, o nó A termina de enviar sua mensagem enquanto os nós B e C reconhecem que uma mensagem correta foi recebida. Os nós B e C, por sua vez, iniciam a arbitragem e, se o nó C vencer a arbitragem, então envia uma mensagem. Os nós A e B reconhecem a mensagem do nó C, e o nó B então continua com sua mensagem. A polaridade oposta da entrada e da saída do circuito de acionamento no barramento deve ser levada em conta. Atualmente, o barramento CAN está amplamente distribuído em carros. Ele está presente em praticamente todos os veículos que estão sendo fabricados. Carros no mundo moderno são essencialmente um produto de mercado global, então todos os veículos tendem a ter um barramento CAN. O acesso ao barramento CAN é feito pela porta OBD, mostrada em uma figura abaixo, juntamente com um exemplo de um resistor de terminação de 120Ω, soldado ao conector DB9 com a fiação CAN, localizado na carcaça do conector DB9. Para ligar a porta OBD a um dispositivo CAN DB9, é necessário um cabo que pode ser comprado ou feito. Para fazer um artesanal, são necessários um soquete D-sub de 9 pinos (fêmea) e um plugue OBD (macho). O soquete DB9 deve corresponder ao plugue do dispositivo CAN. ![CAN e alternativas](https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-29b9ba1c692a1a89298cfff4fc27af89c58b318a%2Fcan-bus-principles-4.png?alt=media) Um exemplo de fiação da porta OBD para CAN DB9, incluindo também um resistor de terminação opcional, é mostrado nos esquemas abaixo. ![CAN e alternativas](https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-dbd222d423e905257463eec2576d2c20fd970e83%2Fcan-bus-principles-5.png?alt=media) Para construir uma rede de sensores, interfacear com um barramento CAN e visualizar os sinais CAN de veículos, há muitas opções. Vários microcontroladores atualmente têm suporte ao protocolo CAN e podem ser interligados ao CAN por meio de um chip transceptor CAN. Também existem soluções como Raspberry Pi, Texas Instruments Launchpad e Arduino, e podem se interligar ao CAN por meio de alguns complementos. A rede de comunicação CAN em veículos modernos pode fornecer um enorme volume de dados que pode ser utilizado em [Gestão de Frotas](https://www.navixy.com/fleet-management/features/) para aumentar a segurança do motorista, reduzir despesas gerais, melhorar os processos de manutenção e apoiar a responsabilidade ambiental. A disponibilização dos dados do barramento CAN oferece aos proprietários de frota várias oportunidades de acessar diversas informações, incluindo consumo de combustível, leituras do odômetro, rotações por minuto, posição do acelerador, carga/torque do motor, temperatura do motor e nível de combustível. ## CAN sem fio O CAN em um par trançado de fios de cobre tornou-se um padrão ISO em 1994. A crescente demanda por maior conectividade leva ao desenvolvimento de tecnologias alternativas e complementares. Por exemplo, algumas opções para transmissão CAN sem fio dependem de padrões de rádio baseados em protocolos, como WLAN ou Bluetooth. Nesse cenário, os dados CAN no transmissor devem ser convertidos para o protocolo sem fio e restaurados no receptor. A transmissão transparente e em tempo real no sentido da rede CAN não é possível dessa forma. A conexão de rádio, portanto, funciona como uma porta de enlace entre duas redes CAN. ![CAN e alternativas](https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-364944e1412069e50e4b64a745a959920a8b82de%2Fwireless-can-diagram.png?alt=media) O CAN sem fio baseado em rádio de modo duplo permite que os participantes do CAN sejam integrados sem fio a uma rede CAN, aumentando a segurança e a usabilidade. No entanto, esse sistema requer antenas especiais que precisam de espaço e de um alinhamento específico que limita a radiação omnidirecional. ## MOST, FlexRay e Ethernet automotiva em resumo Uma alternativa promissora ao CAN é a Ethernet automotiva. Algumas estimativas esperam que o mercado de Ethernet automotiva cresça mais de 21,6% no período previsto de 2019 a 2026. Os principais benefícios da Ethernet para a conectividade veicular são a alta largura de banda e a eficiência de custo. A Ethernet emprega a estratégia Carrier Sense Multiple Access with Collision Detection (CSMA/CD). A colisão pode ser ignorada por meio da divisão nas redes embarcadas. Alguns desafios da Ethernet automotiva são a quantidade significativa de ruído de RF, a incapacidade de fornecer latência na faixa de microssegundos baixos e a falta de uma forma de sincronizar o tempo entre dispositivos. MOST (Media Oriented System Transport) é um sistema de comunicação serial para transmitir dados de controle, vídeo e áudio por meio de fibra óptica [http://cables.It](http://cables.it) fornece uma troca ponto a ponto de informações de som e vídeo com taxas de velocidade de 24,8 Mbps. O MOST, criado pela associação MOST, define as camadas de protocolo, software e hardware necessárias para permitir o transporte eficiente e de baixo custo de dados de controle, em tempo real e de pacotes usando um único meio/camada física. Uma rede MOST poderia ser apresentada esquematicamente na forma de um anel que pode incluir até 64 dispositivos MOST. Graças à sua funcionalidade plug\&play, adicionar ou remover um dispositivo MOST deve ser bastante simples. O FlexRay, por sua vez, é essencialmente um padrão de rede automotiva baseado em um sistema de barramento determinístico, tolerante a falhas, de alta taxa de dados, flexível e de alta velocidade. Ele é utilizado como parte da topologia em estrela ou em linha com cobre ou fibra óptica. As configurações de canal duplo do FlexRay oferecem maior tolerância a falhas e/ou maior largura de banda. A rede de comunicação FlexRay apresenta recursos que a tornam favorável para as indústrias automotivas de próxima geração. ![CAN e alternativas](https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-e4b95247fd9568333d6e0f8ea1f3299162d25d40%2Fflexray_wiring.jpg?alt=media) A maioria das redes FlexRay de primeira geração normalmente emprega um único canal para reduzir os custos de fiação, mas o desenvolvimento adicional da aplicação e os requisitos de segurança envolvidos levarão a um aumento no uso de dois canais. Fatores limitantes para o uso generalizado do FlexRay são o preço, níveis mais baixos de tensão operacional e assimetria de bordas, levando a desafios na extensão do comprimento da rede. Alguns recursos importantes dos protocolos listados em comparação com as características do CAN são apresentados na tabela abaixo. ![CAN e alternativas](https://1173629567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-5ab41e0328dddbe4f3671312560eba5fbf5e5f33%2Fmost-flexray-diagram.png?alt=media) A comparação direta dos protocolos de conectividade listados mostra que há um claro compromisso entre largura de banda e tolerância a falhas versus custos médios e complexidade do sistema. Embora CAN e MOST continuem sendo uma espécie de protocolos fundamentais, FlexRay e Ethernet são soluções mais promissoras para atender às demandas crescentes do mercado e de aplicações de alta carga. Em veículos modernos, esses protocolos são frequentemente usados como soluções complementares. ## Finalidade dos protocolos de comunicação embarcada O barramento CAN é, de fato, um padrão de conectividade veicular bem conhecido e estabelecido. Ele é usado para powertrain, chassi, rede backbone e sistemas da carroceria. A Ethernet, por sua vez, é comumente usada como um protocolo de diagnóstico para unidades de controle eletrônico de motor, chassi e carroceria usadas para conexões de rede. O FlexRay atualmente forma a base do desenvolvimento de tecnologia ativa em todo o mundo, e suas muitas aplicações incluem sistemas X-by-Wire de próxima geração e sistemas backbone. O MOST é um padrão de barramento para redes multimídia veiculares projetado para permitir a transferência de áudio, vídeo e dados de alta qualidade. Ele permite a fácil interconexão de vários componentes multimídia veiculares. Todos os protocolos e tecnologias mencionados acima atendem à maioria dos requisitos de diagnóstico e comunicação multimídia para a comunicação moderna embarcada e veículo a veículo, e podem ser usados para sistemas avançados de condução autônoma. No entanto, a integração precisa dessas tecnologias, ao mesmo tempo em que satisfaz as restrições de tempo real, ainda continua sendo uma parte desafiadora. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://navixy.com/docs/expert-center/pt-br/vehicle-telematics-technology/can-and-obdii/intra-vehicle-communication-can-flexray-and-most.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.