DOU Labs: как в EPAM делают облачную платформу, которая откроет разработчикам доступ в автомобиль

В рубрике DOU Labs мы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на [email protected].

Всем привет. Меня зовут Алекс, я руковожу направлением Automotive & Embedded Systems в EPAM. Чуть больше полутора лет назад мы начали проект разработки облачной платформы для автомобилей. И этим проектом занимаются ребята из киевского офиса. Надеемся, в ближайшие годы он позволит автопроизводителям перестроиться на новые рельсы и глобально подружиться с software и облачными сервисами.

Эта платформа — внутренняя инициатива EPAM. Сегодня мы используем ее как наш value add, когда предлагаем наши услуги для автомобильных компаний.

Расскажу о том, почему мы рассчитываем на успешное использование платформы производителями автомобилей и чем наше облачное решение отличается от других.

Мостик между разработчиками и автоиндустрией

Automotive — интенсивно развивающийся сегмент в любой IT-компании. Автомобильные компании все больше уходят в software, и это прекрасно видно по машинам, которые уже продаются. Все мировые производители поголовно говорят о будущем self-driving car. А мы только успеваем вносить их заявления в презентации.

По объемам индустрия automotive никак не меньше того, что недавно происходило с мобильными или с веб-технологиями. Однако и вызовы она ставит не меньшие. Автомобилестроение в отличие от мобильных, финансовых приложений или e-commerce отличается главным: разработка программного обеспечения для автомобиля сложна и требует жесткого контроля процесса разработки и качества. Потому что автомобиль в случае самой маленькой программной неисправности может травмировать или лишить жизни человека.

Поэтому было бы ошибочно предполагать, что сейчас мы, используя Agile-подход, разработаем на Java, .NET или Python программное обеспечение, которые моментально интегрирует автомобиль в цифровой мир. Автомобильные компании такого не допустят. Причем не потому что не хотят, а исключительно в целях создания безопасного и надежного автомобиля.

К тому же автомобильные компании не умеют разрабатывать digital-сервисы самостоятельно. Для них это всегда делали и продолжают делать подрядчики — опять же, в рамках закрытых монолитных решений.

И вот, допустим, какая-то компания хочет использовать автомобиль в своем бизнес-процессе и должна провести интеграцию с ним с точки зрения программного обеспечения. Если делать по законам разработки ПО для авто, в очень быстром режиме это может занять 1,5 года. В среднем — 2,5-3 года. Для них это нормально. А в digital-индустрии вообще непонятно, зачем начинать разработку, если речь о таких сроках.

Это и есть основной конфликт в диджитализации автомобильной индустрии. Разрабатывать софт по законам и со скоростью digital-индустрии автоотрасль не может. А диджитализация не должна влиять на безопасность — авто 100% должно функционировать без сбоев и проблем.

Так в EPAM родилась идея фундаментальной облачной платформы для connected vehicle — связующего звена между разработчиками digitlal-сервисов и производителями авто.

Не просто еще одна платформа

На первый поверхностный взгляд не очень понятно, в чем революция. Если открыть Google-поиск и набрать «connected vehicle platform», в результатах вывалится порядка 2500 разных продуктов от всех возможных производителей. Зачем нужна еще одна?

Загвоздка в том, что все нынешние варианты рассматривают автомобиль, как монолитное устройство, с которого можно получать данные. Как с датчика движения в умном доме (или пусть даже устройства посложнее).

Схема подобных платформ выглядит примерно так. Вся бизнес-логика для реализации конкретного приложения или сервиса делается на стороне облака. Она рассчитана на то, что данные через всяческие aftermarket devices или специальные Telecommunication Units принимаются из авто и складываются в облако. И только тогда конкретное бизнес-приложение или сервис используют эти данные для реализации бизнес-логики.

Выглядит просто, привычно и понятно, если бы не очевидный минус. Даже два.

  1. Зависимость от постоянного интернет-соединения. Плохая или отсутствующая связь между автомобилем и облаком — это реальность. Связь пропадает — сервис не может работать: данные не передаются, расположение автомобиля неизвестно и т.д. и т.п.
  2. Автомобиль не знает, какие данные могут понадобиться конкретному сервису. Поэтому он делает очень простую вещь — собирает все возможные данные и шлет это большим потоком в облако. Но канал связи между автомобилем и облаком достаточно лимитирован. Получается, что он используется неэффективно. А с учетом того, что эти каналы нигде и никогда не отличаются совершенством, сервис становится нереализуемым.

Поэтому, в отличие от других облачных платформ, в нашем варианте компьютер автомобиля может исполнять часть бизнес-логики. Прямо на нем может исполняться программный код, который я, как вендор сервиса, пишу для каждого конкретного сервиса. Но! Он должен исполняться так, чтобы стопроцентно не затронуть safety и security critical части софта, который обеспечивает безопасное и надежное функционирование автомобиля.

Общая логика платформы такова:

  1. Разработчикам платформа позволяет создавать сервисы без оглядки на то, что одним из элементов сервиса является автомобиль. Они пишут свой сервис теми языками, используя процессы, как уже это делают в мобильных приложениях, e-commerce или cloud services.
  2. Автопроизводители должны без опаски разрешать service vendors интегрировать автомобили в свою систему. Платформа же заботится о том, чтобы бизнес-сервисы никоим образом не спровоцировали сбой в safety и security critical частях ПО. Даже если кто-то разработал сервис с багами.

Так система позволяет совместить два подхода в разработке ПО: классический, сертифицированный waterfall в автомобилестроении и гибкие digital-сервисы с возможностью быстрого изменения бизнес-логики и обновления версий.

Очевидно, что подобная платформа не может существовать без аппаратной поддержки. Мы договорились о партнерстве с японской компанией Renesas Electronics — одним из лидеров по разработке и производству процессоров для автомобильных компьютерных систем. Мы совместно строим платформу, которая хорошо оптимизирована и интегрирована именно с их процессорами, особенно по части safety, security и performance. Но, если возникнет потребность интегрировать платформу с другими процессорами, это тоже возможно.

Если сравнивать наше решение с любой существующей connected platform, подобного сейчас не делает никто. Причина проста: для реализации такого продукта нужно интегрироваться с автопроизводителем на этапе проектирования автомобиля. Это долгий и ресурсоемкий процесс, поэтому разработчики connected vehicle platform ждут, пока автопроизводители дойдут до глубокой интеграции с software.

Мы решили не ждать, а помочь автопроизводителям ускорить этот процесс. И работаем на будущее — 4-5 лет вперед.

Примеры сервисов

Разницу между «традиционными» платформами и продуктом EPAM легко объяснить на примерах.

1. No connection

Эта вещь, которая от разработчика не зависит и может случиться в любой момент. Используя существующие платформы остается только ждать, пока коннект восстановится.

В нашем варианте разработчик может подготовиться: написать специфическую логику для внутриавтомобильной части своего сервиса, которая как-то отреагирует, если связь пропала. Как минимум, будет буферизировать данные, считываемые с машины. А в момент, когда появится связь с интернетом, отослать их в облако.

2. Fleet control

К примеру, компания занимается грузоперевозками. У нее есть набор автомобилей, которые ездят по маршрутам и развозят товар. Компания хочет, чтобы машины оптимально поделили город на небольшие зоны и работали каждая в своей зоне.

Как работают классические платформы? Автомобиль, который катается по зоне А, каждую секунду или полсекунды посылает в сеть свои координаты. Оператор, который сидит «где-то там» за компьютером, следит, чтобы автомобили не выезжали из своих зон. Но вот перегруз сети, место плохого сигнала — и связь между авто и облаком исчезает. Оператору не на что опираться, ведь точка на карте замерла или вовсе пропала. А с ней — и контроль за соблюдением границ рабочей зоны.

В нашем случае разработчик проектирует свой сервис таким образом, что часть логики будет исполняться непосредственно в автомобиле. Например, мы хотим сказать автомобилю № 1 ездить только в зоне А. Из облака на нашу же логику внутри авто мы посылаем команду об этом.

Если связь между автомобилем и облаком пропала, бортовой компьютер сам знает, где должен находиться автомобиль, и контролирует это. В зависимости от того, как будет спроектирован наш сервис, при приближении к границе допустимого района компьютер может вывести водителю предупредительное сообщение на один из экранов. Или начать более активные действия: поморгать фарами, посигналить, уменьшить скорость, припарковаться, включить аварийку. Хотя, конечно, лучше обойтись просто предупреждением.

Все это может работать безо всякой связи с интернетом. Эту логику мы спроектировали, когда думали, как имплементируем свой сервис.

Более того, даже если связь не пропадает, модуль, работающий в автомобиле, может оптимизировать использование коммуникационного канала. Вместо того, чтобы слать GPS-координаты в облако каждую секунду, он может делать это в 5-10 раз реже — чисто для мониторинга. И продолжать контролировать зону нахождения авто изнутри самого авто.

3. Predictive maintenance

Это уже распространенная история с той лишь разницей, что во многом ее работа снова-таки завязана на связь с интернетом. Автопроизводитель мониторит состояние автомобиля. Если в том что-то начинает портиться, водитель получает рекомендацию поехать в гараж и предотвратить поломку, а не стать внезапно посреди дороги с неисправной махиной. Это обоюдно выгодно и производителю, и пользователю.

4. Quality of Service

Как по мне, это самый приземленный и понятный пример.

Представьте, что вы находитесь в Киеве и собираетесь ехать в аэропорт. Вызываете Uber. По правилам сервиса водитель узнает, куда вас вести, только по прибытию к вам. Он приезжает, вы садитесь, называете пункт назначения. И оказывается, что бензина в автомобиле хватит только на полдороги. А вам нужно ехать и побыстрее.

С нашей платформой Uber мог бы установить в автомобиль свой сервис, который еще на этапе заказа мог бы сказать Uber-бэкенду о состоянии автомобиля: сколько бензина в баке, какой расход, подкачены ли колеса. И ситуация с нерелевантной машиной не произошла бы.

Кто участвует в разработке?

Есть три типа software-инженеров, которых мы задействуем в разработке платформы.

Первый — low level embedded developer — эти ребята знают, как правильно работать с железом, виртуализацией, как работает Linux на уровнях kernel-драйверов и т.п.

Второй — классический embedded developer — ребята понимают, как софт разрабатывается и живет во встроенных системах, где есть ограничение по памяти, дисковому пространству, ЦПУ. Что нельзя писать программы и аллоцировать 20 Мб памяти на стэке просто потому, что мне так удобно.

Третий — high level developer — специалисты по разработке распределенных cloud-сервисов. Понимают, что это такое, как делать сервисы, как происходит CI/CD, как строятся сервисы, способные обслуживать большое количество пользователей и оперировать большим количеством данных, как использовать современные облачные технологии и инструменты.

Что до самой структуры, то в автомобильной ее части мы используем подход виртуализации и контейнеризации — для того, чтобы изолировать mission critical ПО от ПО, которое может прийти из облака.

На автомобильном компьютере устанавливается система виртуализации, где есть отдельная виртуальная машина, которая контролируется облаком. В нее могут деплоиться контейнеры.

Контейнеры — не просто обыкновенные, как Docker, а легковесные, которые мы разработали специально для этой платформы. Чтобы более-менее спокойно деплоить что-то из облака в авто, это что-то должно быть небольшим — в пределах нескольких Мб. Во-первых, для автомобиля, у которого на onboard-компьютере всего 2 Гб памяти, привычные cloud-разработчикам контейнеры по 1 Гб — это очень много. Во-вторых, опять-таки нестабильные коммуникационные каналы. И чем меньше будет контейнер, тем больше шансов, что он действительно задеплоится, а не прервется где-то посередине.

Следующий этап — контейнеризация. И верхний уровень — система управления деплойментом между cloud и автомобилем.

Фишка нашей системы в том, что люди, которые разрабатывают сервисы для connected vehicle на базе платформы, ничего специфического про автомобиль знать не должны. Они могут продолжать пользоваться Javascript, .NET, Python или любым другим языком, в котором делают cloud-сервисы. А платформа обеспечит магию: возьмет часть микросервисов, которые должны быть в автомобиле, установит их туда и будет заботиться, чтобы они работали, не вредили друг другу и никак не помешали критическим функциям.

Вызовы, или Что занимает наши головы

Конечно, разработка такой платформы — не прогулка выходного дня. Самая большая сложность — концептуальная. Приходится пробиваться сквозь стереотипы автопроизводителей и объяснять, что правильно разработанное ПО будет помогать, а не вредить. Пока что в их головах cloud, software, Agile = зло.

Если говорить о сложных технических вопросах, решаем следующие:

1. Виртуализация. Все о ней говорят, все понимают, что такое виртуальная машина и зачем она нужна. Но как это использовать в автомобильном компьютере?

Например, есть автомобильный компьютер, на котором установлено несколько виртуальных машин. Машины выполняют разные функции. Как в таком случае управлять power & clock management? Если говорить о классической виртуализации в дата-центрах, у них этот вопрос не стоит: на то и дата-центр. В автомобиле же power & clock management — одна большая задача.

Виртуализация — достаточно тонкая материя, в которой разбирается небольшое количество компаний. Часто на технических переговорах с потенциальными клиентами много времени уходит именно на поиск консенсуса правильной архитектуры с точки зрения виртуализации.

2. Использование GPU. Механические спидометры почти ушли в небытие, а бортовой компьютер выводит все показания на мониторы. Но чтобы это работало и рисовало красивые приборы, нужен GPU. Как поделить его ресурс, когда есть несколько виртуальных машин, которые им пользуются? Что сделать, чтобы внезапная фатальная ошибка GPU от одной из систем, не положило его для других частей?

3. Надежность. Об этом я неоднократно говорил выше, и это приоритетный вопрос. Как правильно построить архитектуру, чтобы cloud software никоим-никоим образом не смогло привести к ошибке в safety software?

Эти и другие архитектурные вопросы обсуждаются в каждом конкретном случае. И это постоянный диалог между нами и потенциальным клиентом.

Мы получаем очень положительные отзывы от автопроизводителей. Хотя все движется медленнее, чем нам бы хотелось, но мы помним, что у автомобилестроения свой таймлайн.

Чтобы концепция прижилась и стала успешной, она обязана быть легкой в использовании и разработке бизнес-приложений и сервисов. В нашем подходе не нужно каждый раз искать разработчиков по embedded и учиться заново — все один раз сделано автопроизводителем. А компании могут сосредоточиться на business value, которых хотят достичь.

Сроки и люди

Над платформой в EPAM работают несколько десятков человек. Мы стартовали в конце 2016 года. В середине 2017-го начали показывать ее потенциальным клиентам. А в этом январе на CES-2018 вместе с Renesas Electronics презентовали платформу широкой общественности.

За все это время у нас не было кардинальных смен маршрута. Понятно, что обычно происходят какие-то поправки и корректировки. Мы говорим с потенциальными клиентами, и у каждого есть свои соображения, ограничения, предпочтения. Мы коллекционируем всю информацию, обрабатываем и решаем, как и что нужно поменять, добавить, убрать.

К примеру, у автомобилистов огромные требования к секьюрити. Поэтому мы постоянно мониторим и апдейтим тему безопасности. Ведь если мы разрешаем облачному сервису установить микросервис прямо в автомобиль, то теоретически можно предположить, что придет злой дядя-хакер и подменит сервис того же Uber на свой зловредный. И нужно понимать, как это не допустить. Или минимизировать последствия.

Команда разработки воспользовалась концепцией американского Агентства национальной безопасности, которая называется Defense in Depth. В нашей платформе мы имплементируем этот подход: многоуровневая система безопасности, при этом каждый уровень независим друг от друга. И если даже злоумышленнику удается взломать один из уровней, он застревает на этом уровне и не может пройти дальше.

Дополнительную секьюрность дают процессоры Renesas — они дают для этого большой спектр hardware-опций. В итоге, количество ресурсов, которое необходимо потратить на взлом, по отношению к бизнес-бенефиту становится непропорционально большим. И эта система постоянно совершенствуется.

На данный момент у нас несколько автопроизводителей на разной стадии пилотных программ. В будущем они приведут нас к продакшн-программам. Нужно понимать таймлайн автоиндустрии — в лучшем случае, даже если все будут очень спешить, рынок и будущие создатели сервисов увидят эту систему лет через пять.

Важный момент напоследок.

Платформу мы делаем на базе open source. И сама система в конечном итоге тоже будет open source. Разрабатывая этот продукт, мы ожидаем, что компании будут приходить к нам за поддержкой и модификацией. Однако если они почувствуют необходимость выстраивать все самостоятельно, у них будут для этого все возможности.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



70 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Первый — low level embedded developer — эти ребята знают, как правильно работать с железом, виртуализацией, как работает Linux на уровнях kernel-драйверов и т.п.

Второй — классический embedded developer — ребята понимают, как софт разрабатывается и живет во встроенных системах, где есть ограничение по памяти, дисковому пространству, ЦПУ. Что нельзя писать программы и аллоцировать 20 Мб памяти на стэке просто потому, что мне так удобно.

Интересная классификация embedded developer’ов. Всегда думал, что low level embedded developer = классический embedded developer, а то что у вас подразумевается под low level embedded developer, это нечто другое.

1. No connection

Эта вещь, которая от разработчика не зависит и может случиться в любой момент. Используя существующие платформы остается только ждать, пока коннект восстановится.

В нашем варианте разработчик может подготовиться: написать специфическую логику для внутриавтомобильной части своего сервиса, которая как-то отреагирует, если связь пропала. Как минимум, будет буферизировать данные, считываемые с машины. А в момент, когда появится связь с интернетом, отослать их в облако.

Не знав, що поточний стан програмного забезпечення в автомобільній галузі настільки сумний. o_0

Если посмотреть на бортовик практически любого автомобиля, то можно увидеть софт, который от мобильного отстает на 5 лет в лучшем случае.

расшифруйте «бортовик»

Имею в виду юзерморду с поганым экраном, экранными кнопочками, стремными шрифтами и тормозным гуём.

«Бортовой комп» имеется в виду «компа экран» на приборной панели куда выводится всякая _доп_ инфа вроде расхода топлива сколько осталось температура воздуха и чаще всего туда комбинируется одометр (счётчик пробега) в свою очередь в таком случае может быть не один (хотя например у отцовской «таврии» всё точно механическое и насколько я помню там одометра таки два) ну а в современных вариантах туда добавляется навигатор (впрочем в «несовременных» он тоже есть только «сильно упрощённый» вроде просто стрелочек куда поворачивать и циферок через сколько метров) ну там название трека который стоит на магнитофоне и... честно говоря х.з. у меня идеи закончились ))

Насчёт «поганого экрана» и пр. крайне сомнительно насчёт «экранных кнопочек» там вообще нет он же ж на приборной панели руками тянуть неудобно кнопки есть на руле либо на подрулевых рычажках насчёт стрёмных и тормознутых х.з. опять же ж сомнительно ни видимо ретину туда никто не ставит хотя опять же ж за деньги любой каприз. ))

ЗЫ: почему не ставят не знаю видимо требования по надёжности и пр.

Ставят, многие японцы используют JDI: www.j-display.com/english/product/am.html — там на любой вкус. У них есть линейка будущего, там вполне себе дисплеи с безумным разрешением и маленьким размером, вот только какой GPU и дисплей контроллер его будет тянуть. Тот же H3 дальше Full HD тянет с трудом как дисплей контроллер. GPU ImgTec RGX ещё вытянет.

Ну с другой стороны я не знаю зачем там hiDpi наверное когда полностью «цифровой кластер» это имеет смысл но если «просто экранчик» он же ж достаточно мелкий и расположен достаточно далеко от глаз чтобы скрадывать любые детали по крайней мере лично я подслеповат чтобы увидеть там 300 дпи ))

ЗЫ: собственно по ссылке так и есть 7.0-inch размер крупного лопатофона желающие могут приложить свой айфон на приборку (там где спидометр) своего авто и там разрешение вполне «неайфонное» 800×480 вот сейчас гляну сколько у айфона в таком размере... iPhone 7 Plus 5,5″ 1920×1080.

он же ж достаточно мелкий и расположен достаточно далеко от глаз чтобы скрадывать любые детали

Хех, у меня в аутлендере в Киеве 2012 года был на кластерной панеле такой экранчик, что пиксели выглядели, как вульфенштайн 3D в режиме 320×200 на 27″ мониторе %) Т.е. экран не очень и маленький, но пиксели тоже, самые пикселизированные, да и расстояние между ними было отчётливо заметно %)

да и расстояние между ними было отчётливо заметно %)

у тебя просто зрение хорошее ))

ЗЫ: ну ок с другой стороны разницу между айпад мини и айпад мини с ретиной я таки вижу уже своими глазами и наверное я вижу пиксели на экранах гольфа 2010-го года и бокстера 2016-го но уверенности у меня нет вот например взять иконки на гольфе я так думаю там таки «физический материал дизайн» читай «дырочки и за ними лампочки» а вот на бокстере у меня уже такой уверенности нет )) и опять же ж посколько и там и там есть циферки в виде... хм... если честно я даже не могу вспомнить там везде циферки в виде 7-сегментных индикаторов или же ж уже отрисованные «настоящим» шрифтом и как-то оно не особо критично один ездит вот уже 7 лет другой ездит вот уже 2 лет.

ЗЫ: при этом новые «цифровые» инструментальные панели мне как-то не особо нравятся я думаю дело привычки и начну пользоваться перестану замечать но то что это «подделка под аналоговые» пока что ещё вижу с первого взгляда ))

ЗЫ: вот кстати да (заглянул в инструкцию что там с приборкой) почему непристёгнутый ремень «подсвечивается» «железной аналоговой иконкой» а незакрытая дверь уже картинкой полностью цифровой на цифровом же ж экранчике?

ЗЫ: при этом новые «цифровые» инструментальные панели мне как-то не особо нравятся я думаю дело привычки и начну пользоваться перестану замечать но то что это «подделка под аналоговые» пока что ещё вижу с первого взгляда ))

Эх, ты не видел редактор для Dodge Hellcat — там можно за ночь такое нарисовать, лишь бы руки не из чресел торчали %)

ЗЫ: вот кстати да (заглянул в инструкцию что там с приборкой) почему непристёгнутый ремень «подсвечивается» «железной аналоговой иконкой» а незакрытая дверь уже картинкой полностью цифровой на цифровом же ж экранчике?

Разная критичность ситуации. Если в двух словах, то для цифровой кластерной панели нужно проходить сертификацию, оборудование должно быть с аппаратной write-back функциональностью, т.е. сигнал с выхода на дисплей заворачиваетсяя назад и захватывается и ложиться опять в память, затем анализируется в рилтайм, не побились ли текстуры и видит ли пользователь то, что должен видеть. У дисплея та же обратная связь, он контроллирует а видет ли пользователь то, что должен видеть или видит битые пиксели. Поэтому каждая такая иконка в цифровом виде — это время на анализ критической информации для безопасности. Возможно они не прошли сертификацию полностью, лишь частично. Поэтому проще сделать аппаратную лампочку и громко пикать, если она перегорела.

Поэтому проще сделать аппаратную лампочку и громко пикать, если она перегорела.

Сурово.

Кстати да если подумать на включении зажигания машина подсвечивает всё аки новогодняя ёлка и не помню уже написано ли в инструкции либо где ещё читал при этом тестирует все свои «аппаратные лампочки» не знаю пикает ли если перегорели пока ничего не перегорело на приборке )) с другой стороны видимо половина или больше светодиодов заднего фонаря уже «ушла» и вот когда это находит таки реально «пикает» «чувак задний правый чёт всё чувак проверь задний правый».

ЗЫ: а вот экран уже цифровой таки вроде никак не проверяет если подумать... и если подумать там и правда ничего критичного в пределе там указатель уровня топлива и всё остальное «чисто интертеймент» включая жпс.

ЗЫ: ок а почему здесь по сабжу чуваки просто не хотят разделить функции как я понимаю это уже сделано сейчас?

ЗЫ: ок а почему здесь по сабжу чуваки просто не хотят разделить функции как я понимаю это уже сделано сейчас?

Кто за девушку платит, тот её и танцует %) Что заказчик скажет, то и делаем. У головастиков из автопрома иногда очень альтернативное видение мира %)

Если в двух словах, то для цифровой кластерной панели нужно проходить сертификацию, оборудование должно быть с аппаратной write-back функциональностью, т.е. сигнал с выхода на дисплей заворачиваетсяя назад и захватывается и ложиться опять в память, затем анализируется в рилтайм, не побились ли текстуры и видит ли пользователь то, что должен видеть.

но этого никто не знает, но рассуждают о «качестве ПО на годы отстающее от мобилок». смех и грех

А я даже не комментирую уже такие посты :)

Ну за устаревшую навигацию стоило бы таки бить)

Давно есть и apple car play и android auto.

ЗЫ: тут должен признать у меня только первый второго не пробовал сравнить не могу ((

Да workaround в виде телефона на присоске всегда есть, но обидно, что машина, которая только в прошлом году пошла в производство, не знает хайвеев и развязок, которые появились за год раньше машины.

Хех, у меня гармин со времен покупки в 2014 иногда показывает чудеса, говорит, поворачивай направо, сейчас срежем! А там лес натуральный и антиоленья сетка сколько видно глазу и только сейчас эту дорогу начали строить через лес %)

хер )) (here) на удивление годны карты и крайне внятная навигация не скажу что перепробовал всё но конкретно эта конкретно совпадает с конкретно моей «личной скоростью восприятия дороги» и «говорит что делать» ровно тогда когда это нужно мне услышать.

И карты на удивление актуальные хотя к.м.к. я ещё ни разу не обновлял а только скачивал новый нужных мест и да оффлайн что работает так вообще торт.

в виде телефона на присоске

У меня наконец дошли руки сделать телефон на присоске ххх лет страдал (видимо 5+) постоянно попадая где-то в не те повороты но это на той машине где нет.

Там где кар плей там айфон просто лежит оно всё само и показывает карту на большом телевизоре самой машины единственное что на маленьком специальном экранчике который уже часть приборки и специально для навигации («родная» показывается там и там) там кар плей не показывается хотя возможно я не нашёл нужной опции правда и не искал.

хз как у других, но в Вольво карты дополняются при наличии соединения

android auto

Это древний, унылый 5.0 андроид.

вы про оффлайн карты?

А у хюндая и многих других вот нет.

Так і не зрозумів, який зв’язок між високими вимогами до надійності апаратного забезпечення, яке вже стоїть у машині, і тим, що автовиробники не встановлюють носій постійної пам’яті достатнього розміру з платою для обчислень, які дозволяли б нормально опрацьовувати ситуації, коли нема інтернету.

Можливо, Ви мали на увазі не мій коментар.

хинт: оффлайн карты
еще вот вольвовский спотифай, например, кеширует все треки
или вы весь интернет предлагаете закешировать?

Кешувати, що є зміст кешувати — одна з оптимізації.

так из какого пальца вы высосали, что это не делается?

Это все известно, но юзера оно не должно волновать, это не его проблемы.

становиться его, как только юзер начинает рассказывать о «качестве кода»

Пользователю нужен хороший целый продукт, а не один только код.

код — основа продукта. хороший код — основа хорошего продукта. из плохого кода хороший продукт не слепишь (наоборот — всегда пожалуйста)

Слишком идеалистично, из плохого кода и костылей порой получаются норм продукты — Facebook, vk, Flickr.

Бизнесу на первых порах всё равно какой код, а вот когда понятно что проект выстрелил, но со скоростью внесения изменений и количеством багов начинаются проблемы. Тогда уже бизнес согласен на работы по приведению архитектуры в порядок.

Но приведённые мной примеры достаточно старые и всё относится к стартап-проектам, а не энтерпрайз миру. И сейчас уровень разработки и инструментов шагнул очень сильно, количество треша по сравнению с тем, что было 10 лет назад, хорошо упало.

норм продукты — Facebook

спорно

«As of the second quarter of 2018, Facebook had 2.23 billion monthly active users».

Пусть даже многим из active users не всё в нём нравится, но был бы проект совсем никудышным, новый какой-то аналог перетащил бы с него user base.

так альтернативы нет. мало того, это гуано еще и не потопляемо, похоже. уже сколько было скандалов, а мышки все продолжают жрать кактус

Согласен насчёт текущих реалий.
Но правильней, думаю, сравнивать с периодом начального становления. В момент старта FB уже был достаточно популярен MySpace. Но проект из говна и палок (fb) тоже стал быстро набирать популярность и в итоге его обошёл, да и похоронил.

А в чому оцінюється «хорошість» продукту?

в лайках? почему вы меня спрашиваете? спросите Кирилла

Цікава думка, ваша в тому числі.

«хороший продукт», как и «хороший человек» — очень субъективно, имхо, поэтому таки в лайках наверное
может есть какието объективные метрики, но чтото навскидку ничего в голову не приходит, кроме количества покупателей на количество возвратов

В мене є тільки одна оцінка: відсоток проблем, які цей проект вирішує. Все інше — суб’єктивщина.

Промежутками времени между процеженными сквозь зубы «what the fuck!».

Если продукт автомобиль, то он может быть хорошим даже без кода.
Если продукт это автомобильная развлекательная система, то качественный по всему эмбеддед феншую код не означает, что можно отдохнуть на всём остальном (тот самый случай).

если под RGX понимается Rogue — то на H3 как раз 6XT и стоит. дисплей контроллер норм вполне себе тянет 2xHD+4K одновременно, на CES вроде демка такая была с графикой и т.д.
но imgtec — не nvidia, конечно.

если под RGX понимается Rogue

Все, кто работает с imgtec не на уровне юзера называют чипы по названию DDK: rgx и sgx — github.com/...​vers/intel_media/graphics

дисплей контроллер норм вполне себе тянет 2xHD+4K одновременно

С точки зрения GPU прокачка по памяти:
3840×2160×4 x 60 = ~1.85Gb/s
2×1920×1080×4 x 60 = ~1Gb/s
С точки зрения дисплей контроллера такая же: ~2.85Gb/s, итого имеем 5.7Gb/s только для отображение информации. Если используется multi-plane графика, а этот чип имеет пачку VSPx контроллеров, то эту цифру нужно умножить на 4. При использовании 2-4-6 камер имеем похожу нагрузку и всё, четырёхканальный контроллер памяти в самой дорогой конфигурации улетел в трубу только на обслуживание графики и всё, что с ней связано. Для демки — это ок, для реальной работы нет.

А причем софт, к фрагменту который вы цитируете? Это проблемы аппаратные, а точнее коммуникационной составляющей.

Можливо, я помиляюся і проблеми апаратні: замало пам’яті чи ще щось. Але у такому випадку це виглядає ще дивніше, бо ціна пам’яті у порівнянні з ціною автомобіля взагалі смішна.

бо ціна пам’яті у порівнянні з ціною автомобіля взагалі смішна.

)) за среднюю размер доплаты за «цветной экранчик большого размера мультимедийной системы + бла бла бла» в авто люкс и даже чуть пониже класса можно купить 2-3 айфона новый в коробочке х.з. почему так но факт.

ЗЫ: не знаю как у кого из производителей а в наши дни фольксваген сильно попустило наличи заводов в Китае (оригинальных притом) с которых видимо выливается на рынок по почте масса конкретно оригинала конкретно нового за ценники там пусть будет 100-200 евро вместо 1000-2000 «от производителя» причём таки да первый точно тот же ж самый «от производителя» ))

какое отношение отсутствие интернета имеет к нанешнему состоянию ПО автомобиля, и что не так с нынешним состоянием ПО автомобиля?

Не відсутність інтернету, а (IMHO) неоптимальне проектування ПО. Мобільні телефони як мінімум 10 років тому вміли при відсутності інтернету дані або буферизувати, або використовувати для роботи офлайн. Зауважте, що апаратна складова автомобіля дорожча, ніж в телефона, тому автомобіль може дозволити собі більше ресурсів (процесор, пам’ять), і ситуація з джерелом живлення простіша.

вы пытаетесь дискутировать о вещах, о которых не имеете ни малейшего представления
на цену влияет надежность. те же требования к температурному режиму гораздо строже
во вторых, в современном автомобиле порядка сотни нод (электронных блоков). все их надо запитать
весь етот зоопарк должен работать как часы
ит тд ит тп, лень все описывать. так что сначала изучите матчасть

У такому випадку розкажіть, скільки коштує постійний носій пам’яті, у якого надійність і температурний режим підходящі для автомобіля) Скільки коштує автомобіль, ми приблизно знаємо.

обратитесь к supply manager-у своего автопроизводителя

Во-первых, для автомобиля, у которого на onboard-компьютере всего 2 Гб памяти

На H3 2Gb RAM???

на SoC H3 нет совсем никакого RAM. на SOMах R-Car gen3 бывает 2, 4, 8 ГБ

R-Car gen3 бывает 2, 4, 8 ГБ

Я же спрашивал про H3, а не в общем про gen3. На картинке нарисовано H3, в тексте сказано 2Gb. Вот мне стало интересно, на сколько нужно не понимать архитектуру, чтобы всунуть туда 2Gb.

H3 SOMы есть с 4 и 8 ГБ. Платформа работает и на М3.

Поэтому было бы ошибочно предполагать, что сейчас мы, используя Agile-подход, разработаем на Java, .NET или Python программное обеспечение

так на чем же написана автомобильная часть платформы?

С (системные компоненты), C++ (либы), Go (весь стафф OCI)

откроет разработчикам доступ в автомобиль

Звучит как реализация алгоритма «Выдерни шнур, выдави стекло».

у нас есть сервис краткосрочной аренды Traficar, там доступ в автомобиль открывается путем сканирования QR-кода телефоном.

И что для этого понадобилось глубокое внедрение во внутренности авто сертифицированное производителем и палатой стандартов?

По Израилю на арендных машинах стоит какая-то сигналка с кодом на всех стоит сел код ввёл тогда только поехал стоит отдельно т.е. «торчит отдельно» вполне себе надо полагать работает и никакого «глубокого внедрения в софт и железо авто» надо полагать не предполагает.

По Киеву я слышал можно поставить сигналку любой там сложности включая такую чтобы с 5-этажки выходишь на пульте ДУ кнопочку княпнул машина завелась и принялась прогреваться мол пока дошёл до гаражика машинка уже тёплая тоже спокойно и безо всяких «трёх эмбедеров и одного питониста и ста пиэмов» делают надо полагать ставят на все машины надо полагать производителя обратно не спрашивают.

Но в целом да ок когда машина становится сложной и с кучей компов со всем этим начинаются скорее вопросы но опять же ж они начинаются скорее от того что производитель не очень хочет делиться технической инфой а с другой стороны CAN шина промышленный стандарт сервисный порт есть почти у всех у кого только есть CAN шина всё те же ж «сервисные сканеры» как тут пишут:

Если в том что-то начинает портиться, водитель получает рекомендацию поехать в гараж и предотвратить поломку, а не стать внезапно посреди дороги с неисправной махиной. Это обоюдно выгодно и производителю, и пользователю.

— прекрасно продаются и надо полагать имеют спрос и своего потребителя уже... уже вчера?

Fleet Control в ту же ж степь ставится отдельный блок включая свой GSM/GPS и вперёд и с песней заем ему «встроенная интеграция в виртуальную машину авто» непонятно даже более того к.м.к. чисто технически чревато нечего ему там делать а главное всё уже есть не нужно это никому.

BMW Combox 7 или 8 лет назад по моему разработан (я даже чуть-чуть принимал участие). Там все это есть — удаленная диагностика и техподдержка и машина условно сама едет до ближайшего сервис-центра (точнее сервер присылает маршрут для навигации). Все давно уже придумано.

Підписатись на коментарі