> 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 ao multiplexar a fiação elétrica nos 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 para a 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 maior 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 da 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 dele Em sentido amplo, o barramento CAN (Controller Area Network-bus) é, na verdade, um conjunto de padrões que permitem 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, o que o torna mais resistente a ruídos, com dois estados lógicos: recessivo e dominante. Hoje em dia, o barramento CAN é usado praticamente em tudo, desde máquinas de café até [gestão de frotas](https://navixy.com/en/fleet-management/) e aplicações espaciais. Descrevemos brevemente os princípios de funcionamento do barramento CAN a seguir. O protocolo de comunicação 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 da organização dos bits em quadros e inclui dois protocolos: o CAN clássico (o primeiro uso remonta a 1988) e o CAN FD (lançado em 2012). A camada de aplicação é essencialmente uma camada voltada ao usuário final e fornece acesso aos recursos da rede. Há dois tipos de formatos de mensagens/quadros: padrão e estendido. Eles diferem entre si apenas pelo comprimento do identificador — um padrão tem 11 bits, enquanto um estendido tem 29 bits. Uma estrutura de mensagem padrão 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 de prioridade da mensagem), Remote Transmission Request (RTR, indica se um nó solicita dados de outro nó ou envia dados), Control (informa o comprimento dos dados em bytes), Data (valores de dados reais que precisam ser escalados/convertidos), A verificação de redundância cíclica (CRC, garantindo a integridade dos dados), ACK (confirmação, indica se os dados estão sendo recebidos corretamente) e EOF (Fim do Quadro), 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) O barramento CAN utiliza uma forma invertida de lógica com dois estados: dominante e recessivo. A figura acima demonstra um diagrama simplificado de entrada e saída de um transceptor CAN: fluxo de bits indo para e vindo 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. Para 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 Ω a 130 Ω). Não deve haver mais do que dois resistores de terminação na rede, já que terminação adicional coloca carga extra sobre os circuitos de acionamento. A imagem abaixo mostra um barramento de teste CAN. Os nós podem representar o envio de mensagens de tecnologia de sensoriamento inteligente e de um controlador de motor. Uma aplicação típica pode 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ó 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 confirmam o recebimento correto de uma mensagem. Os nós B e C, por sua vez, iniciam a arbitragem e, se o nó C vencer a arbitragem, ele envia uma mensagem. Os nós A e B confirmam 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. Hoje em dia, o barramento CAN é amplamente difundido em carros. Ele está presente em praticamente todos os veículos que estão sendo produzidos. Os 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 barramento CAN é acessado por meio da porta OBD, mostrada em uma figura abaixo juntamente com um exemplo de resistor de terminação de 120 Ω, soldado ao conector DB9 com a fiação CAN, localizado na carcaça do DB9. Para conectar a porta OBD a um dispositivo CAN DB9, é necessário um cabo que pode ser comprado ou feito. Para ter um feito por você, 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 da fiação do plugue OBD para DB9 CAN, incluindo um resistor de terminação opcional, também é 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 criar uma rede de sensores, interligar-se a 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 há soluções como Raspberry Pi, Texas Instruments Launchpad e Arduino e elas podem se interligar ao CAN por meio de alguns complementos. A rede de comunicação CAN em veículos modernos pode fornecer um grande volume de dados que pode ser utilizado em [gestão de frotas](https://navixy.com/en/fleet-management/) 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 impulsiona o desenvolvimento de tecnologias alternativas e complementares. Por exemplo, algumas opções para transmissão de CAN sem fio dependem de padrões de rádio baseados em protocolo, como WLAN ou Bluetooth. Em tal cenário, os dados CAN no transmissor devem ser convertidos para o protocolo sem fio e redefinidos no receptor. A transmissão transparente e em tempo real no sentido da rede CAN não é possível dessa forma. Assim, a conexão de rádio funciona como uma porta de ligação 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, tal sistema requer antenas especiais que precisam de espaço e de um alinhamento específico, o que limita a radiação omnidirecional. ## MOST, FlexRay e ethernet automotiva em resumo Uma alternativa promissora ao CAN é a ethernet automotiva. Algumas estimativas preveem que o mercado de ethernet automotiva crescerá mais de 21,6% no período de previsão de 2019 a 2026. Os principais benefícios da ethernet para a conectividade veicular são alta largura de banda e eficiência de custos. 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 uma quantidade significativa de ruído de RF, a incapacidade de fornecer latência na faixa de microssegundos baixos e a falta de um mecanismo para 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 cabos de fibra óptica [Ele](http://cables.it) oferece uma troca ponto a ponto de informações de som e vídeo com velocidades de 24,8 Mbps. Criado pela associação MOST, 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 em pacotes usando um único meio / camada física. Uma rede MOST pode 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 flexível, determinístico, tolerante a falhas e de alta velocidade e alta taxa de dados. Ele é utilizado como parte da topologia em estrela ou em linha com cobre ou fibra óptica. Configurações de canal duplo do FlexRay oferecem maior tolerância a falhas e/ou maior largura de banda. As características da rede de comunicações FlexRay tornam-na 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) As redes FlexRay de primeira geração normalmente empregam um único canal para reduzir os custos de fiação, mas o desenvolvimento futuro de aplicações e os requisitos de segurança associados levarão ao aumento do uso de dois canais. Os fatores limitantes para o uso disseminado do FlexRay são o preço, os níveis de tensão operacional mais baixos e a assimetria das bordas, levando a desafios na extensão do comprimento da rede. Algumas características principais dos protocolos listados em comparação com as características do CAN são apresentadas 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á uma clara compensação entre largura de banda e tolerância a falhas versus custos médios e complexidade do sistema. Embora CAN e MOST continuem sendo 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 embarcados O barramento CAN é de fato um padrão de conectividade veicular bem conhecido e estabelecido. Ele é usado para trem de força, chassi, rede troncal e sistemas de carroceria. A ethernet, por sua vez, é comumente usada como um protocolo de diagnóstico para as unidades de controle eletrônico de motor, chassi e carroceria usadas para conexões de rede. Atualmente, o FlexRay forma a base do desenvolvimento tecnológico ativo em todo o mundo, e suas muitas aplicações incluem sistemas X-by-Wire de próxima geração e sistemas troncais. 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 interconexão fácil 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 entre veículos, e podem ser usados em sistemas avançados de direçã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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` 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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.