> 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/ru/vehicle-telematics-technology/can-and-obdii/intra-vehicle-communication-can-flexray-and-most.md). # Внутриавтомобильная связь: CAN, FlexRay и MOST Бортовые сети используют CAN, FlexRay, MOST и Ethernet для связи ЭБУ. Каждый протокол рассчитан на разные требования к скорости, надежности и пропускной способности. CAN, FlexRay и MOST — это автомобильные протоколы связи, используемые для соединения электронных блоков управления (ECU), блоков управления трансмиссией (TCU) и модулей управления кузовом (BCM) в транспортных средствах: * **CAN**\ Протокол, основанный на сообщениях, изначально был разработан для экономии меди за счет мультиплексирования электрической проводки в автомобилях. Пропускная способность CAN составляет около 125 кбит/с. * **FlexRay**\ Высокоскоростной, отказоустойчивый и детерминированный последовательный протокол связи, который может передавать данные со скоростью до 10 Мбит/с по двум витым проводам. FlexRay часто используется в критически важных для безопасности приложениях, таких как модули силового агрегата. Полезная нагрузка FlexRay, или кадры данных, может достигать 127 слов (254 байта), что более чем в 30 раз превышает длину полезной нагрузки CAN. * **MOST**\ Стандарт шины для автомобильных мультимедийных сетей, который позволяет передавать высококачественные аудио, видео и данные. MOST доступен в трех скоростях передачи: MOST25, MOST50 и MOST150. CAN (Controller Area Network) в настоящее время является наиболее широко используемой бортовой сетью. Однако с непрерывным развитием автономных транспортных средств и связанных технологий растет спрос на большую пропускную способность и связность. В этом документе мы кратко описываем CAN и другие варианты связи для транспортных средств, включая беспроводной CAN, MOST, FlexRay и автомобильный Ethernet. ## Шина CAN: некоторые принципы работы В широком смысле CAN-bus (Controller Area Network-bus) — это на самом деле набор стандартов, которые позволяют различным устройствам обмениваться данными друг с другом. Это асинхронная (со сдвигом по времени) последовательная шинная система, разработанная в 1983 году Robert Bosch GmbH с целью объединить электронные блоки управления (ECU) в моторных транспортных средствах. CAN был разделен на различные слои в соответствии с моделью ISO/OSI, чтобы обеспечить гибкость и прозрачность проектирования. На практике для связи шина CAN использует два выделенных провода: CAN low и CAN high, с помощью которых контроллер CAN подключается ко всем компонентам сети. CAN позволяет заменить довольно сложную проводку двухпроводной шиной. CAN использует дифференциальный сигнал, что делает его более устойчивым к помехам, с двумя логическими состояниями: рецессивным и доминантным. Сегодня шина CAN используется практически повсеместно — от кофемашин до [управление транспортом](https://navixy.com/en/fleet-management/) и космических приложений. Далее мы кратко описываем принципы работы шины CAN. Протокол связи CAN ISO-11898:2003 объясняет, как информация передается между устройствами в сети на основе модели взаимодействия открытых систем (OSI), которая на рисунке ниже представлена в виде набора слоев. Два нижних слоя семислойной модели OSI/ISO — это физический и канальный слои. Физический уровень определяет связь между устройствами, соединенными физической средой. ![CAN и альтернативы](https://2371323805-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\&token=46ded095-43c9-4f95-80ca-dbb28c457213) Канальный уровень, помимо прочего, также отвечает за организацию битов в кадры и включает два протокола: классический CAN (первое использование относится к 1988 году) и CAN FD (представленный в 2012 году). Прикладной уровень, по сути, является уровнем конечного пользователя и предоставляет доступ к сетевым ресурсам. Существует два типа форматов сообщений/кадров: стандартный и расширенный. Они отличаются друг от друга только длиной идентификатора — стандартный составляет 11 бит, а расширенный — 29 бит. Структуру стандартного сообщения можно разделить на 8 частей, как показано на рисунке ниже. Это: Start of Frame (SOF — начало передачи кадра), CAN-ID (идентификатор кадра, определение приоритета сообщения), Remote Transmission Request (RTR, указывает, запрашивает ли узел данные у другого узла или передает данные), Control (указывает длину данных в байтах), Data (фактические значения данных, которые нужно масштабировать/преобразовать), Check Cyclic Redundancy (CRC, обеспечивающая целостность данных), ACK (подтверждение, указывает, корректно ли принимаются данные) и EOF (End of Frame), обозначающий конец сообщения/кадра CAN. ![CAN и альтернативы](https://2371323805-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\&token=a8cebc8d-213c-4c17-8883-91ee41c90278) Шина CAN использует инвертированную логику с двумя состояниями: доминантным и рецессивным. На рисунке выше показана упрощенная схема входа-выхода CAN-трансивера: поток битов, идущий к/от контроллера CAN и/или микроконтроллера. Когда контроллер отправляет поток битов, они инвертируются и подаются на линию CANH. Линия CANL всегда является инверсией CANH. CAN должен контролировать как то, что в данный момент находится на шине, так и то, что он отправляет. Для практического применения оба конца шины CAN должны быть согласованы, поскольку любой узел на шине может передавать данные. На каждом конце линии имеется согласующий резистор, равный волновому сопротивлению кабеля. Обычно рекомендуемое значение согласующих резисторов составляет 120 Ом (в диапазоне 100–130 Ом). В сети не должно быть более двух согласующих резисторов, поскольку дополнительные согласования создают дополнительную нагрузку на драйверы. На рисунке ниже показана тестовая шина CAN. Узлы могут представлять отправку сообщений от интеллектуальной сенсорной технологии и контроллера двигателя. Типичным примером применения может быть датчик температуры. ![CAN и альтернативы](https://2371323805-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\&token=2f9550e7-28e3-4068-9aa4-69271279a2d6) Если другому сенсорному узлу нужно отправить сообщение одновременно, арбитраж обеспечивает его передачу. Например, узел A завершает отправку своего сообщения, а узлы B и C подтверждают корректное получение сообщения. Затем узлы B и C, в свою очередь, начинают арбитраж, и если узел C выигрывает арбитраж, он отправляет сообщение. Узлы A и B подтверждают сообщение от узла C, а узел B затем продолжает передачу своего сообщения. Следует помнить об обратной полярности входа и выхода драйвера на шине. Сегодня шина CAN широко распространена в автомобилях. Она присутствует практически во всех выпускаемых транспортных средствах. Автомобили в современном мире по сути являются продуктом глобального рынка, поэтому все транспортные средства, как правило, оснащаются шиной CAN. Доступ к шине CAN осуществляется через порт OBD, который показан на рисунке ниже вместе с примером согласующего резистора 120 Ом, припаянного к разъему DB9 с проводкой CAN, расположенному в корпусе DB9. Для подключения порта OBD к устройству CAN с разъемом DB9 нужен кабель, который можно либо купить, либо изготовить самостоятельно. Чтобы изготовить его самостоятельно, требуются 9-контактное гнездо D-sub и штекер OBD. Гнездо DB9 должно соответствовать штекеру устройства CAN. ![CAN и альтернативы](https://2371323805-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\&token=5a99e860-78b5-4e15-a62d-c601fca762ad) Ниже на схемах также показан пример подключения штекера OBD к CAN DB9, включая опциональный согласующий резистор. ![CAN и альтернативы](https://2371323805-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\&token=bfd97d43-dca0-480a-a535-9a9f13ebc03e) Для построения сенсорной сети, подключения к шине CAN и просмотра сигналов CAN от транспортных средств существует множество вариантов. В настоящее время различные микроконтроллеры поддерживают протокол CAN и могут быть подключены к CAN через микросхему CAN-трансивера. Также существуют такие решения, как Raspberry Pi, Texas Instruments Launchpad и Arduino, которые могут подключаться к CAN с помощью некоторых дополнений. Сеть связи CAN в современных транспортных средствах может предоставлять огромный объем данных, который можно использовать для [управление транспортом](https://navixy.com/en/fleet-management/) повышения безопасности водителя, снижения общих затрат, улучшения процессов техобслуживания и поддержки экологической ответственности. Предоставление данных шины CAN открывает владельцам автопарка различные возможности для доступа к информации, включая норму расхода топлива, показания одометра, обороты в минуту, положение дроссельной заслонки, нагрузку/крутящий момент двигателя, температуру двигателя и уровень топлива. ## Беспроводной CAN CAN на витой паре медных проводов стал стандартом ISO в 1994 году. Растущий спрос на повышенную связность стимулирует разработку альтернативных и дополняющих технологий. Например, некоторые варианты передачи беспроводного CAN опираются на радиостандарты на основе протоколов, таких как WLAN или Bluetooth. В таком сценарии данные CAN в передатчике должны быть преобразованы в беспроводной протокол и обратно преобразованы в приемнике. Прозрачная передача в реальном времени в рамках сети CAN таким образом невозможна. Таким образом радиосоединение функционирует как шлюз между двумя сетями CAN. ![CAN и альтернативы](https://2371323805-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-364944e1412069e50e4b64a745a959920a8b82de%2Fwireless-can-diagram.png?alt=media\&token=3bb6cfe6-fa0e-4e3f-9600-bc6dd15f259d) Беспроводной CAN, основанный на двухрежимном радио, позволяет участникам CAN беспроводным образом интегрироваться в сеть CAN, повышая безопасность и удобство использования. Однако такой системе требуются специальные антенны, которым нужно место и определенная ориентация, ограничивающая всенаправленное излучение. ## Кратко о MOST, FlexRay и автомобильном Ethernet Перспективной альтернативой CAN является автомобильный Ethernet. Согласно некоторым оценкам, рынок автомобильного Ethernet вырастет более чем на 21,6 % в прогнозный период 2019–2026 годов. Ключевые преимущества Ethernet для транспортной связи — высокая пропускная способность и экономическая эффективность. Ethernet использует стратегию Carrier Sense Multiple Access with Collision Detection (CSMA/CD). Коллизии можно игнорировать за счет разделения в бортовых сетях. Некоторые проблемы автомобильного Ethernet — значительное количество радиочастотных помех, невозможность обеспечить задержку до низкомикросекундного диапазона и отсутствие способа синхронизации времени между устройствами. MOST (Media Oriented System Transport) — это последовательная система связи для передачи управляющих данных, видео и аудио с помощью волоконно-оптических [кабелей. Это](http://cables.it) обеспечивает обмен звуковой и видеоинформацией по схеме «точка-точка» со скоростью 24,8 Мбит/с. MOST создан ассоциацией MOST и определяет уровни протокола, программного и аппаратного обеспечения, необходимые для эффективной и недорогой передачи управляющих данных, данных реального времени и пакетных данных с использованием единой среды / физического уровня. Сеть MOST может быть схематически представлена в виде кольца, которое может включать до 64 устройств MOST. Благодаря функции plug\&play добавление или удаление устройства MOST должно быть довольно простым. FlexRay, в свою очередь, по сути является стандартом автомобильной сети, основанным на гибкой детерминированной, отказоустойчивой и высокоскоростной шинной системе с высокой скоростью передачи данных. Он используется в топологиях звезды или линии с медными проводниками или оптоволокном. Конфигурации FlexRay с двумя каналами обеспечивают повышенную отказоустойчивость и/или большую пропускную способность. Эти особенности сети связи FlexRay делают ее привлекательной для автомобильной промышленности следующего поколения. ![CAN и альтернативы](https://2371323805-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-e4b95247fd9568333d6e0f8ea1f3299162d25d40%2Fflexray_wiring.jpg?alt=media\&token=951928ef-89ce-4834-b6a9-4201a348b4ff) Большинство сетей FlexRay первого поколения обычно используют один канал, чтобы сократить затраты на проводку, но дальнейшее развитие применения и связанные с ним требования безопасности приведут к более широкому использованию двух каналов. Ограничивающими факторами широкого применения FlexRay являются цена, более низкие уровни рабочего напряжения и асимметрия фронтов, что создает трудности при увеличении длины сети. Некоторые ключевые особенности перечисленных протоколов по сравнению с характеристиками CAN представлены в таблице ниже. ![CAN и альтернативы](https://2371323805-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-5ab41e0328dddbe4f3671312560eba5fbf5e5f33%2Fmost-flexray-diagram.png?alt=media\&token=cd43359e-c562-4b00-8631-864ea1f3e1b7) Прямое сравнение перечисленных протоколов связи показывает, что существует явный компромисс между пропускной способностью и отказоустойчивостью, с одной стороны, и средними затратами и сложностью системы — с другой. Хотя CAN и MOST остаются своего рода базовыми протоколами, FlexRay и Ethernet выглядят более перспективными решениями для удовлетворения растущих требований рынка и приложений с высокой нагрузкой. В современных транспортных средствах эти протоколы часто используются как взаимодополняющие решения. ## Назначение протоколов внутритранспортной связи Шина CAN действительно является хорошо известным и устоявшимся стандартом бортовой связи. Она используется для силового агрегата, шасси, магистральной сети и кузовных систем. Ethernet, в свою очередь, обычно используется как диагностический протокол для электронных блоков управления двигателем, шасси и кузовом, используемых для сетевых подключений. FlexRay в настоящее время служит основой активной разработки технологий по всему миру, а в число его многочисленных применений входят системы X-by-Wire следующего поколения и магистральные системы. MOST — это стандарт шины для автомобильных мультимедийных сетей, предназначенный для обеспечения передачи высококачественного аудио, видео и данных. Он позволяет легко соединять различные автомобильные мультимедийные компоненты. Все перечисленные выше протоколы и технологии удовлетворяют большинству требований диагностики и мультимедийной связи для современных систем внутритранспортной и межтранспортной связи и могут использоваться для передовых систем автономного вождения. Однако точная интеграция этих технологий при соблюдении ограничений реального времени по-прежнему остается сложной задачей. --- # 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/ru/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.