> 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-bus) на самом деле представляет собой набор стандартов, которые позволяют разным устройствам взаимодействовать друг с другом. Это асинхронная (с временным сдвигом) последовательная шинная система, разработанная в 1983 году Robert Bosch GmbH с целью объединения электронных блоков управления (ECU) в автотранспортных средствах. CAN был разделен на различные слои в соответствии с моделью ISO/OSI, чтобы обеспечить гибкость и прозрачность проектирования. Для связи на практике шина 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. Некоторые оценки ожидают, что рынок автомобильного Ethernet вырастет более чем на 21,6 % за прогнозный период 2019–2026 годов. Ключевые преимущества Ethernet для связи в транспортных средствах — высокая пропускная способность и экономическая эффективность. Ethernet использует стратегию множественного доступа с контролем несущей и обнаружением коллизий (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 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.