для потрепаться
- Автор темы Turbobazar
- Дата начала
Именно в плане шины Ethernet решения как раз будут отлажены, так как в телекоме это юзается пару десятилетий уже, в промышленной автоматике десяток лет. Использование в авто на мой взгляд даст положительные эффекты:
- адресная передача пакетов, чего нет в том же кане. Дропать ненужные пакеты будет Ethernet модуль, а не проц с протоколом верхнего уровня. Кроме того, адресная передача пакетов подразумевает возможность коммутации, что станет актуально, когда количество модулей управления в авто будет расти. Коммутируемые 10 МБит/с - это видео в режиме реального времени для каждого блока в авто;
- размер фрейма с полезной информацией - от 46 до 1500 байт. Это перекрывает все возможные потребности в обмене данными между модулями, а с учетом шины 10МБит/с скорость обмена пакетами - единицы мс, настоящий реалтайм)));
- учитывая стандартный кадр Ethernet, для диагностики не требуются никакие адаптеры, витая пара в диагностический разъем. Для настройки аналогично;
- опять же, стандартный кадр Ethernet подразумевает возможность при наличии модуля выхода в интернет передавать все данные о авто в любую точку мира, без всякого конвертирования;
- для обмена внутри авто не обязательно накручивать TCP/IP, для такого размера сети можно попроще что-нибудь запилить. Да и даже если TCP/IP запустить, то с учетом шины 10 МБит все будет ок. Обработку Ethernet и IP пакетов можно на одном модуле коммуникации поднять, без нагрузки на проц.
Вероятно, плюсы и другие есть, нужно только копнуть глубже)
Другой момент, что на сегодняшний день и кана вроде как достаточно для всех нужд и вкладываться в развитие новой шины выгоды нет никакой. Вот когда каждый сверчок в авто будет слать данные о своем состоянии в шину, тогда актуальность будет другой.
- адресная передача пакетов, чего нет в том же кане. Дропать ненужные пакеты будет Ethernet модуль, а не проц с протоколом верхнего уровня. Кроме того, адресная передача пакетов подразумевает возможность коммутации, что станет актуально, когда количество модулей управления в авто будет расти. Коммутируемые 10 МБит/с - это видео в режиме реального времени для каждого блока в авто;
- размер фрейма с полезной информацией - от 46 до 1500 байт. Это перекрывает все возможные потребности в обмене данными между модулями, а с учетом шины 10МБит/с скорость обмена пакетами - единицы мс, настоящий реалтайм)));
- учитывая стандартный кадр Ethernet, для диагностики не требуются никакие адаптеры, витая пара в диагностический разъем. Для настройки аналогично;
- опять же, стандартный кадр Ethernet подразумевает возможность при наличии модуля выхода в интернет передавать все данные о авто в любую точку мира, без всякого конвертирования;
- для обмена внутри авто не обязательно накручивать TCP/IP, для такого размера сети можно попроще что-нибудь запилить. Да и даже если TCP/IP запустить, то с учетом шины 10 МБит все будет ок. Обработку Ethernet и IP пакетов можно на одном модуле коммуникации поднять, без нагрузки на проц.
Вероятно, плюсы и другие есть, нужно только копнуть глубже)
Другой момент, что на сегодняшний день и кана вроде как достаточно для всех нужд и вкладываться в развитие новой шины выгоды нет никакой. Вот когда каждый сверчок в авто будет слать данные о своем состоянии в шину, тогда актуальность будет другой.
а какого рода данные в эбу требуют такой пропускной способности? вот с примерами желательно и оценкой размера.
ну и если предложишь, то следом вопрос - а какой мк сможет настрогать столько данных, притом что ему еще надо мотор пинать, соблюдая тайминги.
Также следом вопрос - а где хранить то эти данные? То-есть условно берем 1 мбайт/секунду, если требуется перекидывать не что-то конкретное, а абстрактно-избирательное, то где-то должно лежать условно 20 мегабайт сырых данных, актуальных и нужных, причем если это не просто логи а данные для постобработки самим же эбу (dsp итд) то не забывать про конскую нагрузку шины/мк даже с учетом повального DMA. Да и я не припомню эбух даже с примерно такими объемами RAM и алгоритмами.
ну и у ethernet разъем по-моему нифига не автомобильный, и для юзера он неособо неудобен - допустим на ноуте специфические настройки сети, каждый раз перенастраивать свойства адаптера.
ну и если предложишь, то следом вопрос - а какой мк сможет настрогать столько данных, притом что ему еще надо мотор пинать, соблюдая тайминги.
Также следом вопрос - а где хранить то эти данные? То-есть условно берем 1 мбайт/секунду, если требуется перекидывать не что-то конкретное, а абстрактно-избирательное, то где-то должно лежать условно 20 мегабайт сырых данных, актуальных и нужных, причем если это не просто логи а данные для постобработки самим же эбу (dsp итд) то не забывать про конскую нагрузку шины/мк даже с учетом повального DMA. Да и я не припомню эбух даже с примерно такими объемами RAM и алгоритмами.
ну и у ethernet разъем по-моему нифига не автомобильный, и для юзера он неособо неудобен - допустим на ноуте специфические настройки сети, каждый раз перенастраивать свойства адаптера.
Пропускная способность шины определяет не только размер данных, но и тайминги между пакетами. Пусть даже проц будет отправлять 10-20 байт данных, а остальное в пакете будет балласт, шина 10МБит/с позволит эти пакеты отправлять раз в 1-2 мс.
На текущий момент да, согласен, в такой шине потребности нет. Да и вряд-ли в ближайшее время потребность эта возникнет. Но ведь когда-то и к-лайн не в каждом авто был)))
Что касается разъемов, то там предполагается промышленный стандарт разъема. отличный от привычного нам RJ-45
На текущий момент да, согласен, в такой шине потребности нет. Да и вряд-ли в ближайшее время потребность эта возникнет. Но ведь когда-то и к-лайн не в каждом авто был)))
Что касается разъемов, то там предполагается промышленный стандарт разъема. отличный от привычного нам RJ-45
ну езернет он всетаки p2p шный на физическом уровне, всех в кучу не собрать на скрутках, арбитраж сan тут вне конкуренции, если конечно не планируется тачку обвешивать eth-свитчами
ну я не вижу особой проблемы разогнать rs485 до скорости 1..5 мбит (ведь в авто не нужны километры линии) и на физическом уровне там задержек никаких не будет ведь это обычный uart, вопрос только как быстро винда с USB преобразователем выгребет стек. Помехоусточивость почти как у CAN шины, оверхеда траффика вообще почти нет по сравнению с CAN, преобразователь стоит гроши на али (по сравнению с can-свистками), и требований к разъемам никаких нет. Я б если делал эбу то присрал бы rs485 в качестве интерфейса связи с ноутом, клиния для всяких бк и легаси пусть болтается, а can для штатных систем, все таки присутствие диагностики не должно вмешиваться в равномерность служебного трафика.
ну я не вижу особой проблемы разогнать rs485 до скорости 1..5 мбит (ведь в авто не нужны километры линии) и на физическом уровне там задержек никаких не будет ведь это обычный uart, вопрос только как быстро винда с USB преобразователем выгребет стек. Помехоусточивость почти как у CAN шины, оверхеда траффика вообще почти нет по сравнению с CAN, преобразователь стоит гроши на али (по сравнению с can-свистками), и требований к разъемам никаких нет. Я б если делал эбу то присрал бы rs485 в качестве интерфейса связи с ноутом, клиния для всяких бк и легаси пусть болтается, а can для штатных систем, все таки присутствие диагностики не должно вмешиваться в равномерность служебного трафика.
RS-485 всем хорош, за исключением того, что это физический уровень, а реализация протоколов верхнего уровня начиная с канального ложится на проц. В эзернет канальный уровень как минимум на модуле связи, причем именно в железной реализации.
Ну и интеграция в глобальные сети с RS-485 по простому пути не получится.
Ну и интеграция в глобальные сети с RS-485 по простому пути не получится.
а в чем там сложность если для работы ПО ноута <-> эбу ненужно ничего кроме запрос/ответ? Преамбула, сериализованные данные и crc как в модбасе - вполне достаточно чтобы гнать трафик в стиле kwp2000 (если бы не тупой checksum то и kwp тоже сгодился бы). А тратить время/цп на сериализацию тебе полюбому придется хоть эзернет хоть что угодно.
а ты хочешь непосредственно эбу в интернет пускать? Если нет, то в любом случае сокетные дела проще через комп заворачивать, а там уже спокойно преобразовывать RS485 в глобалтрафик. Если да, то вообще зачем? У нас появились облачные провайдеры муток с ЭБУ? когда он сам заходит на глобалхост и пишет туда поток? Ну и в целом имхо никто не мешает через rs485 гнать PPP протокол в котором твои IP пакеты, не знаю только как там на уровне драйверов винды можно ли такое принимать (если эбу будет эмулировать обычный модем на COM порту то помоему без проблем, и даже индикатор сети будет в таскбаре гореть с желаемым битрейтом)
а ты хочешь непосредственно эбу в интернет пускать? Если нет, то в любом случае сокетные дела проще через комп заворачивать, а там уже спокойно преобразовывать RS485 в глобалтрафик. Если да, то вообще зачем? У нас появились облачные провайдеры муток с ЭБУ? когда он сам заходит на глобалхост и пишет туда поток? Ну и в целом имхо никто не мешает через rs485 гнать PPP протокол в котором твои IP пакеты, не знаю только как там на уровне драйверов винды можно ли такое принимать (если эбу будет эмулировать обычный модем на COM порту то помоему без проблем, и даже индикатор сети будет в таскбаре гореть с желаемым битрейтом)
Последнее редактирование:
ну коммерческая телематика и охранная тема у контор типа ***айна давно вроде реализована уже. Но там масштабы заинтересованности другие совсем.
а вот танцы вокруг настройки спорт эбу с применением облака - сомнительно. это даже звучит непонтово, только безумец будет вкладываться в такой стартап ради 30 заказов
а вот танцы вокруг настройки спорт эбу с применением облака - сомнительно. это даже звучит непонтово, только безумец будет вкладываться в такой стартап ради 30 заказов
ну коммерческая телематика и охранная тема у контор типа ***айна давно вроде реализована уже. Но там масштабы заинтересованности другие совсем.
а вот танцы вокруг настройки спорт эбу с применением облака - сомнительно. это даже звучит непонтово, только безумец будет вкладываться в такой стартап ради 30 заказов
а вот танцы вокруг настройки спорт эбу с применением облака - сомнительно. это даже звучит непонтово, только безумец будет вкладываться в такой стартап ради 30 заказов
Мысль про интерфейс "in cloud" с завода-производителя. Обновление различных модулей по воздуху (стоит ли компенсировать эти затраты дилеру, когда можно провернуть все без его участия?), полная телематика состояния авто (пробег, ошибки, перегревы, перекруты, краши и т.д.) в облаке. Даже по окончанию гарантии историю авто можно продавать третьим лицам при купле-продаже на вторичном рынке.
завод изготовитель без всего этого разберется, там надо неподступно+дешево (в серии)+надежно+с сертификатами евроХ (это наверно самое дорогое), не говоря уже о том чтобы клиенты заезжать к ОД не забывали с оплатой регламентых работ. Да и кому упали еще десятки тыщ лишних договоров с опсосами в серийной продукции.
я же исключительно про наследие января для строителей моторов и корчей говорил. Когда есть кастом мотор и эбу должен его раскрывать при любом конфиге и режиме, и желательно с минимумом затрат на катание таблиц.
я же исключительно про наследие января для строителей моторов и корчей говорил. Когда есть кастом мотор и эбу должен его раскрывать при любом конфиге и режиме, и желательно с минимумом затрат на катание таблиц.
Последнее редактирование:
