> 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-шина (шина Controller Area Network) — это фактически набор стандартов, позволяющих различным устройствам обмениваться данными друг с другом. Это асинхронная (со сдвигом по времени) последовательная шинная система, разработанная в 1983 году Robert Bosch GmbH с целью объединения электронных блоков управления (ECU) в автомобилях. Согласно модели ISO/OSI, CAN был разделен на различные слои для обеспечения гибкости и прозрачности проектирования. На практике для связи CAN-шина использует два выделенных провода: CAN low и CAN high, посредством которых контроллер CAN подключается ко всем компонентам сети. CAN позволяет заменить довольно сложную проводку двухпроводной шиной. CAN использует дифференциальный сигнал, что делает его более устойчивым к помехам, с двумя логическими состояниями: рецессивным и доминантным. В настоящее время CAN-шина используется практически повсюду — от кофемашин до [управление автопарком](https://www.navixy.com/fleet-management/features/) и космических приложений. Ниже мы кратко описываем принципы работы 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) Канальный уровень, помимо прочего, также отвечает за организацию битов в кадры и включает два протокола: классический CAN (первое применение датируется 1988 годом) и CAN FD (представленный в 2012 году). Прикладной уровень по сути является уровнем конечного пользователя и обеспечивает доступ к сетевым ресурсам. Существуют два типа форматов сообщений/кадров: стандартный и расширенный. Они отличаются друг от друга только длиной идентификатора: у стандартного он составляет 11 бит, а у расширенного — 29 бит. Стандартная структура сообщения может быть разделена на 8 частей, как показано на рисунке ниже. Эти части: Start of Frame (SOF — начало передачи кадра), CAN-ID (идентификатор кадра, идентификация приоритета сообщения), Remote Transmission Request (RTR, указывает, запрашивает ли узел данные у другого узла или отправляет данные), Control (сообщает длину данных в байтах), Data (сами значения данных, которые нужно масштабировать/преобразовать), The Cyclic Redundancy Check (CRC, обеспечивающий целостность данных), ACK (acknowledge, указывает, корректно ли принимаются данные) и 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) 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) Если другому сенсорному узлу нужно отправить сообщение одновременно, арбитраж обеспечивает отправку сообщения. Например, узел A заканчивает отправку своего сообщения, а узлы B и C подтверждают, что сообщение получено корректно. Затем узлы B и C начинают арбитраж, и если узел C выигрывает арбитраж, он отправляет сообщение. Узлы A и B подтверждают сообщение от узла C, а узел B затем продолжает отправку своего сообщения. Следует помнить об обратной полярности входа и выхода драйвера на шине. CAN-шина сегодня широко распространена в автомобилях. Она присутствует практически во всех выпускаемых транспортных средствах. Автомобили в современном мире по сути являются глобальным рыночным продуктом, поэтому все транспортные средства, как правило, имеют CAN-шину. Доступ к CAN-шине осуществляется через порт OBD, который показан на рисунке ниже вместе с примером оконечного резистора 120 Ом, припаянного к разъему DB9 с проводкой CAN, расположенной в корпусе разъема DB9. Для подключения порта OBD к устройству CAN с разъемом DB9 нужен кабель, который можно купить или изготовить самостоятельно. Чтобы сделать его своими руками, требуются 9-контактная розетка D-sub (female) и штекер OBD (male). Розетка 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) Пример подключения разъема 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) Для создания сети датчиков, подключения к CAN-шине и просмотра сигналов CAN с транспортных средств существует множество вариантов. Различные микроконтроллеры сейчас поддерживают протокол CAN и могут подключаться к CAN через микросхему CAN-трансивера. Также существуют решения вроде Raspberry Pi, Texas Instruments Launchpad и Arduino, которые могут подключаться к CAN с помощью дополнительных модулей. Сеть CAN в современных транспортных средствах может предоставлять огромный объем данных, который можно использовать для [управление автопарком](https://www.navixy.com/fleet-management/features/) повышения безопасности водителя, сокращения общих расходов, улучшения процессов техобслуживания и поддержки экологической ответственности. Включение данных 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) Беспроводной CAN, основанный на двухрежимной радиосвязи, позволяет беспроводным образом интегрировать участников CAN в CAN-сеть, повышая безопасность и удобство использования. Однако такая система требует специальных антенн, которым требуется место и определенная ориентация, ограничивающая всенаправленное излучение. ## MOST, FlexRay и автомобильный Ethernet кратко Перспективной альтернативой CAN является автомобильный Ethernet. По некоторым оценкам, в прогнозируемом периоде 2019–2026 годов рынок автомобильного Ethernet вырастет более чем на 21,6 %. Ключевые преимущества 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) Сети 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) Непосредственное сравнение перечисленных протоколов подключения показывает, что существует явный компромисс между пропускной способностью и отказоустойчивостью, с одной стороны, и средними затратами и сложностью системы — с другой. Хотя 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 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/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 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.