Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Особенности виртуализации Xen в автомобильной сфере

Я Lead Software Engineer, занимаюсь проектами по виртуализации для автомотив-сектора в GlobalLogic. Эта статья подготовлена на основе моего выступления на Root Linux Conference 2017, и является продолжением темы, которую недавно раскрыл Ларс Курт.

В течение последних 5 лет GlobalLogic активно занимается проектами в автомобильной сфере. Некоторые из них — изначально коммерческие, некоторые — экспериментальные прототипы (proof of concept или попросту PoC), часть из которых также впоследствии перешла на коммерческую основу. Одно из наиболее интересных и важных для нас направлений в этой сфере — это технологии виртуализации. В этой статье я расскажу о том, зачем они нужны и как работают, а также затрону основные проблемы, с которыми мы столкнулись в процессе разработки, а также способы их решения.

Начнем с того, почему технологии виртуализации сейчас особенно актуальны для автомобильной индустрии. В любом современном автомобиле среднего уровня (не говоря уже про машины премиум-класса) используется 2-3 разных компьютера.

Один из них отвечает за работу информационно-развлекательной системы автомобиля (радио, воспроизведение музыки, навигация — все то, что мы привыкли видеть в своем смартфоне). Как правило, эта система работает на базе Android, но могут быть исключения, например, Tizen.

Другой компьютер (в обычной жизни водитель взаимодействует с ним редко) отвечает за систему зажигания, сервисы экстренного оповещения при аварии и т. п. Этот компьютер работает под управлением операционной системы реального времени (real-time OS, RTOS), как правило, закрытой и/или проприетарной (впрочем, бывают и исключения, например, FreeRTOS или QNX). Главные требования к такой системе — стабильность, надежность и отзывчивость, поскольку это устройство обслуживает запросы, время выполнения которых очень ограничено и очень критично.

Также в автомобилях премиум-класса отдельный компьютер отвечает за работу кластера (приборная панель над рулем автомобиля). Как правило, такой компьютер работает под управлением какой-либо узкоспециализированной Linux-системы с композитным менеджером Weston. Главное требование к такой системе — быстрый и высококачественный рендеринг изображения. В противном случае показания спидометра или тахометра будут отображаться на панели с задержкой, что сделает их бесполезными для водителя.

Один за всех

Теперь рассмотрим типичную автомобильную платформу. Как правило, это очень производительная система: 8-ядерный процессор: четыре А57, четыре А53, высококлассный PowerVR GPU от Imagination, 4 Гб оперативной памяти, огромное разнообразие разных шин. Для решения каждого конкретного набора задач — будь-то кластер или информационно-развлекательные системы — ее возможности явно избыточны. Поэтому мы решили, что можно совместить несколько физических компьютеров в одном за счет использования виртуализации. Какие преимущества мы получаем от такого использования?

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

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

В-третьих, экономия денег и времени происходит на этапе поддержки и обновления программного обеспечения всей системы. Дело в том, что в случае с виртуализацией мы можем модернизировать и обновлять систему не целиком, а отдельными частями. Например, после выхода Android Z мы можем достаточно быстро портировать его в нашу информационно-развлекательную систему. При этом такое обновление никак не повлияет на работу кластера или других систем. Если же виртуализации у нас нет, то, обновляя информационно-развлекательную систему, мы будем вынуждены обновлять и другие системы, что, вероятно, потянет за собой вопросы сертификации, безопасности и т. п. В свою очередь, это не только усложняет процесс обновления (и требует большей квалификации разработчиков), но и растягивает его на длительное время.

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

Почему Xen?

Во-первых, Xen — это гипервизор так называемого первого типа (type 1), что позволяет его использовать на «голом железе» и стартовать практически любую операционную систему в качестве гостевой. Уже, как говорится, «из коробки» Xen поддерживает множество гостевых операционных систем: Windows, Linux, FreeBSD, QNX и еще много чего другого, пускай даже с некоторыми ограничениями.

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

В-третьих, начиная с версии 4.4, в Xen появилась поддержка архитектуры ARM, что называется, «из коробки». Нам не приходится каждый раз добавлять отдельную поддержку, поскольку она стабильная, надежная и тестированная.

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

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

Как это работает?

Итак, у нас есть несколько операционных систем, которые управляются из так называемого Dom0. Это привилегированный домен, который может управлять аппаратной платформой почти без ограничений. В основном он ответствен за создание гостевых операционных систем, за их модификацию и удаление. Также очень эффективно, чтобы в Dom0 «бежал» Watchdog, который поддерживается Xen через специальный механизм. Так, если упадет какой-либо из гостевых доменов, Watchdog его легко поднимет без влияния на работу остальных систем.

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

Кроме того, в Dom0, как правило, работают драйвера физических устройств. Это такой специальный тип драйверов, который позволяет использовать их одновременно несколькими операционными системами с помощью паравиртуализированного подхода. Суть этого подхода в том, что мы предоставляем интерфейс (через специально написанные драйвера-прослойки) для использования физических устройств гостевым операционным системам (так называемые DomU), например, для воспроизведения звука или вывода изображения на экран. При этом в реальности все драйвера этих устройств находятся в другом домене — Dom0.

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

Проблемы и решения

Ранее уже упоминалось, что в Xen есть поддержка архитектуры ARM. Что нужно, чтобы операционная система «бежала» на основе гипервизора на ARM? На ARM операционная система «бежит» в режиме EL2 на AArch64, а гостевые домены у нас в EL1-режиме. Основная проблема для автомотива и не только — это проблема перевода бутлоадера перед стартом гипервизора в нужный режим.

В общем случае для решения этой проблемы используется U-boot. Но это далеко не обязательно, есть достаточно много исключений. Плюс иногда этот перевод не общедоступен, поскольку иногда это достаточно проприетарная информация. Но тем не менее U-boot с 2016 года поддерживает автоматический перевод ARM архитектур в Virtualization mode. Т. е. мы прыгаем на само ядро, в данном случае на гипервизор уже в Virtualization mode. Поэтому основной проблемой является отсутствие стандартизированного подхода в общем случае и некоторая закрытость инфраструктуры, особенно если мы говорим о закрытых архитектурах, например, Qualcomm.

Память

Еще одна достаточно сложная и комплексная задача — это память. Давайте рассмотрим вариант с трехдоменной конфигурацией. Как работает память в Xen в общем случае? У нас есть понятие физического и машинного адреса. Физический — это тот адрес, который мы видим со стороны домена. Ну, домен думает, что он бежит по физическим адресам. В действительности в терминологии Xen он «бежит» через промежуточные адреса по машинным адресам. Они в лучшем случае могут не соответствовать тем адресам, по которым будут бежать гостевые домены либо Dom0 за крайне редким исключением.

Расположение доменов памяти по умолчанию в трёхдоменной конфигурации

Dom0 специально настроен и работает таким образом, что его внутреннее представление адресов и машинное представление адресов, с которыми он взаимодействует, одинаковое. Зачем это нам надо? Проблема в том, что в Dom0 находятся все физические драйверы. Как минимум одна из проблем — это проблема с DMA.

Когда мы создаем DMA-транзакцию, то должны работать с машинным адресам в терминологии Xen (то есть настроить буфера на эти адреса, но это не всегда возможно, так как для гостевых операционных систем машинные и физические адреса будут разными). Есть несколько способов сделать это так, чтобы сами гостевые операционные системы знали об этом и использовали тот факт, что у них физические адреса не соответствуют машинным. Один из них, очень грязный хак — это правка стартового начального адреса памяти, по которой «бежит» конкретная операционная система. Это так называемая RAM base.

Подправленное размещение DomainD в памяти (память нарезана одним цельным куском) — DomainD rambase подправлен для получения 1:1 замапленного домена

По умолчанию Xen создает RAM base начиная с 0×80000000, но это можно изменить. И по факту это больше механическая работа, потому что это нельзя сделать в один проход. Вам надо править в нескольких местах, начиная с конфигурации конкретного домена, заканчивая конечным device tree. Но тем не менее это имеет право на жизнь — на схеме можно увидеть, что Xen выделил память для драйвера домена с 0xB0000000 — 0xBFFFFFFF, но сама операционная система драйвер-домена думала, что она бежит по адресам начиная с 0×80000000. Однако мы поправили стартовый адрес, и теперь у нас домен один в один замаплен.

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

Память для DomainD набирается автоматически из нескольких кусков, каждый из которых 1:1 замаплен

Вторым подходом является набор памяти по частям. Xen изначально оперирует достаточно большими кусками памяти, и не всегда их можно «нарезать» таким механизмом. Нам, например, надо 766 МБ в драйвер-домене. Если не ошибаюсь, ближайшее целое значение памяти, которое мы можем выделить одним куском, — 1 ГБ, после этого будет уже мелкими кусочками по 2MB. Нам никто не мешает, в принципе, эти кусочки натягать из разных частей оперативной памяти и сделать так, чтобы каждый из них был один в один «замаплен». Это нам позволит переложить работу по трансляции адресов на ядро. Да, хорошо, у нас будут какие-то дырки, у нас будет и непрерывный кусок, но вся трансляция проходит на стороне Linux. На данный момент это наиболее эффективный подход, который мы используем.

Наиболее правильным и эффективным методом решения проблемы с DMA будет использование SMMU (IOMMU) (SMMU — system mmu, IOMMU — input/output mmu) — в этом случае трансляция адресов будет выполняться на аппаратном уровне, прозрачно для устройства. Но, к сожалению, его наличие в SoC зависит от производителя (и наличия поддержки этого устройства в BSP для данного SoC). А также поддержки со стороны Xen — но сообщество работает над этим решением.

Графика и прошивки

Следующая проблема, с которой можно столкнуться, — это проблема с прошивками. Например, у нас есть какой-то DSP-процессор (узкоспециализированный процессор, предназначенный для решения задач цифровой обработки сигналов), который обрабатывает видео и, как правило, использует резерв памяти в device tree для ARM. В общем случае доступ к этим прошивкам есть только у производителей устройств. И проблема в том, что нам надо получить доступ к функциональности этих прошивок, не смотря на то, что процессор использует резерв. К сожалению, эта проблема сложно решаема. Одно из банальных решений, к которому приходилось прибегать, — это бинарный патч в runtime. Мы знаем, по каким адресам у нас бежит домен, и мы в runtime просто патчим адреса, на которые настроена прошивка для DSP. Это очень грязный хак, но тем не менее иногда он имеет право на жизнь.

Другой подход, который в принципе сейчас невозможен в силу специфических требований некоторых заказчиков и производителей, — это отказ от использования какого-то программного обеспечения или устройств периферии в гостевых доменах. При этом, разумеется, мы хотим каким-то образом взаимодействовать, например, с GPU. Готового решения этой задачи нет, но наиболее правильным и эффективным методом, как указывалось раньше, будет использование SMMU.

По своей сложности топовые GPU (например, A72 Mali) уже превосходят привычные вычислительные процессоры. Это создает разработчикам дополнительные проблемы — сложность самого графического «железа», жесткие проприетарные лицензии, проблемы с документацией, которую очень непросто получить от производителя.

Также на данный момент в 99% GPU отсутствует поддержка аппаратной виртуализации, поэтому приходится искать какие-то отдельные варианты и механизмы для решения этих задач.

Один из способов использования GPU виртуализированными операционными системами, который мы реализовали, — это программный context switch. На каждый switch домена мы сохраняем состояние и набор регистров GPU и восстанавливаем с другого домена. То есть процесс повторяется: сохранили-восстановили; сохранили-восстановили. Этот механизм достаточно прост в создании, но проблема, как минимум, в том, что GPU весьма сложное устройство, и все эти операции — не мгновенные.

Чем больше регистров мы сохраняем, тем больше времени мы теряем в процессе context switch. Поэтому надо сохранять минимальный набор регистров. Плюс для такого подхода характерно включение/выключение GPU. На каждом этапе мы должны его выключать/включать, что в терминах железа не является быстрым процессом. Нам надо ждать каких-то битов в регистрах, ждать значения в памяти и прочее.

Вторым, более эффективным подходом является использование полуаппаратной виртуализации. Это виртуализация с поддержкой со стороны GPU. В таком случае мы перекладываем часть работы на железо, которое позволяет нам сохранять состояние графического процессора. Однако это требует весьма больших затрат в поддержке со стороны виртуализации в драйверах. Это реализовано в некоторых драйверах с помощью производителя, что позволяет упростить и более корректно это сделать. Дело в том, что любая поддержка виртуализации в принципе не зависима от гипервизора, на котором мы «бежим».

Если говорить о производительности решений, то первое решение, конечно, менее производительно, потому что мы должны все это прогнать через CPU, что весьма долго. Так, потеря производительности в первой платформе составляет порядка 5-10%. На второй платформе — всего 3% в трехдоменной конфигурации. Самым правильным является использование полной графической поддержки виртуализации. Но, насколько нам известно, это существует буквально в нескольких чипах, и в автомотиве они пока не используются, но может найдут свое применение уже через пару лет.

PV-драйвера

Как уже говорилось ранее, PV-драйвера — это некий специальный подход к распределению возможностей реального железа между несколькими доменами. У нас есть какой-то backend, который взаимодействует с аппаратным программным обеспечением через настоящий драйвер в Linux и какой-то frontend, который предоставляет не обязательно полный доступ ко всей функциональности.

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

Поначалу «из коробки» были доступны только основные драйверы — PV-блок, который используется для виртуализации блочных устройств. Паравиртуальные драйверы для сети и PCI, SCSI и Frame buffer, а также USB (pvUSB) были доступны только на архитектуре x86. PvUSB было изначально доступно и в более старых версиях, но производительность была очень низкой, как и переносимость, но вот в 4.7 добавили базовую поддержку pvUSB. Однако коммюнити продолжает разрабатывать другие PV-драйвера.

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

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

Тренды и перспективы

Одно из самых интересных для автомотива направлений — это операционные системы реального времени. Как я уже говорил, работа некоторых бортовых встроенных компьютеров критична с точки зрения времени, они важны для того, чтобы оповестить об определенных событиях, чтобы защитить человека. Xen имеет некоторые механизмы поддержки RTOS, но, к сожалению, они еще не очень развиты.

По умолчанию Xen использует scheduler, который weight-based, то есть рассчитан на работу с весами. Он не гарантирует отзывчивость операционной системы. Есть также механизм RTDS scheduler, который предоставляет мягкое реальное время, но он на данный момент еще в разработке. Интересен для автомотива ARINC653 scheduler: он позволяет предоставить жесткое реальное время, но не имеет поддержки многоядерности. В дальнейшем, возможно, это будет исправлено, возможно, нет.

Также на сегодняшний день достаточно интересным трендом, как я уже говорил, является дезагрегация — использование отдельного драйвер-домена. Почему бы нам в качестве Dom0 не использовать какую-нибудь тонкую операционную систему реального времени, FreeRTOS, например? Это позволит нам более эффективно взаимодействовать с железом, отслеживать его состояние, поддерживать состояние системы в целом.

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

Также нами была разработана частичная поддержка QNX в качестве гостевого домена DomU. Это позволило нам воспользоваться его преимуществами для дальнейшей сертификации. Кроме того, в качестве Dom0 можно использовать Linux с реал-тайм патчами. Но он, конечно, не предоставит механизм жесткого реального времени. Этого будет недостаточно для каких-то критичных по времени исполнения задач.

В целом можно сказать, что виртуализация для автомобильной промышленности — достаточно сложная область, и здесь хватает задач, для которых пока еще нет готовых решений. Но именно поэтому это очень интересная тема для всех, кто хочет попробовать себя в R&D и заняться созданием решений, которые, возможно, станут стандартом для целой индустрии. В любом случае это очень перспективное направление. Если оно интересно и вам — присоединяйтесь. Больше про Xen и все, что с ним связано, вы можете узнать на странице wiki.xen.org/wiki/Main_Page

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

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

Схожі статті




114 коментарів

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

И при этом дико повышается потребность в резервировании+по безопасности и отказоустойчивости в данном случае — я бы ОЧЕНЬ СИЛЬНО поспорил.Они, как ни крути, остаются теми же (безопасность и отказоустойчивость ОДНОГО компьютера)- если вы не задублируете эту систему (создав кластер хотя бы из двух гипервизоров), что для автомобиля — жизненно важно.

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

Опять же — нет. Хорошая и производительная embedded машинка будет стоить НАМНОГО дороже чем 3-4 посредственных. А если еще учесть дублирование агрегата...

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

Какая экономия денег ? Для клиента — все равно, что ехать обновлять на СТО софт на виртуалке, что на отдельном бортовом компьютере. А, ну правда добавится обновление гипервизора. Опять же — дополнительные деньги.

Может оно и стоит того, но в каких- нибудь лакшери карах, типа наклейка «Virtualized by XEN». Для простых машинок лучше обычная схема.

Ні, XEN буде стояти в опенсорсних, «зроби-сам», автоконструкторах :)))
В лакшері буде стояти QNX: www.qnx.com/...​x/en/products/hypervisor .
Тільки Майку не кажіть.

Тільки Майку не кажіть.

Майк и так в этом всём, что аж ночные кошмары мучают %)

З якогось дива, QNX вирішив провести вебінар про віртуалізацію: ®Tag=&sourcepage=register" target="_blank">event.on24.com/...​®Tag=&sourcepage=register

Там можна навіть спитати нащо воно їм :)))

Там можна навіть спитати нащо воно їм :)))

Вопрос не в том, зачем оно нам — это и так понятно — хочет автопроизводитель, а вот зачем автопроизводителям, никто на него тут и не ответил :) В другой теме тоже.

Ето, мамінька, нинчє модньо. 8-)

Ответ тривиальный, с европейскими законами про выхлопные газы, стало необходимо аццки экономить на бортовом электричестве, чтобы останавливать и запускать движок на каждом светофоре. Почему-то кто-то решил, что мощный комп, который никогда не спит лучше двух лоу пауэр, которые работают толком не просыпаясь. Реально мозги выносят за каждые 250 милливатт потребления GPU, заставляя играть частотами всего, чего можно как токкатту Баха на трехклавиатурном органе с тремя сетами педалей.

Мда. Из-за дурости политиков — для разработчиков гимор.И надежность подобной системы резко падает.

Ні, це просто прогрес.

Ти у Artem Mygaiev спитай, нащо він останні чотири роки активно просуває віртуалізацію по вендорах, таєрах, і чіп-мейкерах :)

Треба ж побільше людей на проект подовше

Ви категорично неправі.
Деталі під НДА. Але було надзвичайно весело. Як технічно, так і організаційно. В результаті -
чисто аутсорсингова конторка GL продає свій(sick) продукт Nautilus.

У EPAM раптом з"явився свій продукт fusion :)
www.linux.com/...​fety-internet-cars#post-1

Наверное, потому что кушать хочет :)

О! Я зрозумів чому QNX напиляв свій гіпервізор.

Битый линк — не открывается.

дивно, у мене теж...
а вчора відкривалося.

це доу пожувало лінку

Спасибо. Но что-то там при регистрации в поле должность можно выбирать только топ-менеджеров(

Як мені прийшло, так я виклав:)
Що вам заважає відчути себе топом на один вебінар? ;)

Потому что будут продавать :) а не выкладывать технические детали :)

Частиною продажу будуть красиві казки: нащо ж та віртуалізація треба:)

А тут набіжать голодні ембедери з україни і почнуть якісь противні питання задавати(

Врядли. Это вебинар для тех, кто знает зачем он там. Как я уже говорил ранее в этой теме, Intel заходит на рынок Automotive с рядом очень серьёзных заявок. Только и всего :) И на виртуализации они не один десяток собак съели, так что остальным придётся потесниться %)

Intel заходит на рынок Automotive с рядом очень серьёзных заявок

Це вже було.
І буде знову.

BayTrail — это low end, это было прощупывание почвы.

Це було і до Bay Trail.

Например?

Давно це було. Ще тоді коли код QNX зробили відкритим.
Не на довго, і дуже специфічно:)

В те времена, когда навигационный софт работал только под Windows CE? Это automotive с большим натягом, не больше, чем GPS навигатор с hands free висящий на присоске на стекле. Доля интела, там кстати, была очень приличная.

так что остальным придётся потесниться

А цього ще не було (в автомотіві).
І цього разу навряд чи буде.

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

готовности софта всех существующих и будущих платформ,

А тут стає критичним консервативність automotive.

Это одна из причин, почему я резко высказываюсь по этой теме. Вы все работает в сложной сфере, делаете сложные продукты, которые кому-то нужны, но не надо подрабатывать аналитиками, при этом находясь в пузыре, как виртуализированая гостевая операционная система. Консервативность automotive есть только для low и в лучшем случае для mid-range cars, в этом сегменте вы и работаете. Но есть и другой automotive, который работает с ещё невыпущенным железом. Часто железо запускается в массовое производство вместе с выходом авто. Многие часто путают консервативность с long-term support.

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

Спасибо, нам очень приятно, что наши друзья из GL пишут про достижения команды xen-troops в EPAM! Мы ещё апстримим поддержку op-tee, shared coprocessor framework, non-vmsa ipmmu, и многое другое, материала может хватить на несколько статей, пишите ещё! :D

Мне например, непонятно чем Xen будет лучше скажем вариантa Linux + LXC + Docker?
Еще одна универсальная прокладка, на которой бы работали Guest-ы разных типов и одинаково хреново.

Xen — это гипервизор так называемого первого типа (type 1), что позволяет его использовать на «голом железе»

В свое время сталкивался с Oracle VM(XEN). Там грузится обычное линуксовое ядро
«Oracle VM Server: includes a version of Xen hypervisor technology..... It also includes a minimized Linux kernel as Dom0.»
Так в чем смысл?

Мне например, непонятно чем Xen будет лучше скажем вариантa Linux + LXC + Docker?

чем виртуализация серверов лучше контейнерной виртуализации приложений?
чем теплое лучше мягкого?
в конце концов — чем грузины лучше чем армяне?

Ну хотя бы тем, что:
— одна базовая ОС
— будет работать быстрей виртуалок.
— проще деплоить приложения.
— проще инфраструктура.

одна базовая ОС

это можеть быть не плюс — а минус

будет работать быстрей виртуалок

тоже — нет

проще деплоить приложения

ага, особенно если приложения вообще под другую ОС :-)

Во-первых, это безопасность и устойчивость к отказам.

Как виртуализация может повысить безопасность и устойчивость? Что может быть устойчивее и безопаснее выделенного компа под каждую из задач?

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

Это не так. Во-первых у разных производителей разная ценовая политика. Например, Интел отдает свои ApolloLake автопроизводителям по очень вкусной цене, чтобы зайти на рынок. А Renesas H3 стоит как два Renesas M3, так что это очень слабое доказательство.

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

Ну это тоже очень слабое утверждение, наоборот нужно поддерживать хост и все виртуалки, что дороже в плане поддержки, чем такое же количество независимых хостов.

Также на данный момент в 99% GPU отсутствует поддержка аппаратной виртуализации

Это абсолютно не так! Я надеюсь, мы не рассматривает архаичные древности типа SGX.

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

Это тоже абсолютно не так.

Также нами была разработана частичная поддержка QNX в качестве гостевого домена DomU.

Смысла в этом действии 0.0% :) Смысл появляется только если QNX обслуживает Dom0.

Также на данный момент в 99% GPU отсутствует поддержка аппаратной виртуализации
Это абсолютно не так!

приведите хоть один пример для ARM

Nvidia tegra

и каким боком данная SoC к GPU-sharing?

Самым прямым.

это ж не какой-нибудь Quadro — нет там никакой аппаратной поддержки GPU-sharing

Вот, объясни, с чего ты взял что её там нет? Что заставляет тебя так утверждать?

это не я так сам придумал — это информация вендора
у кого-то есть другая версия?

это не я так сам придумал — это информация вендора

Прямо так и заявили, что в наших Паркерах нет аппартной виртуализации? Я тебе не верю. С какой стати аутомотив подразделению nVidia с тобой вообще делиться какой-либо информацией?

у кого-то есть другая версия?

blogs.nvidia.com/...​er-for-self-driving-cars
На CES2016 и CES2017 они вполне недвусмысленно заявляли о полной поддержке виртуализации на аппаратном уровне для всего.

заявляли о полной поддержке виртуализации

тут налицо непонимание разницы между поддержкой виртуализации вычислительной платформой и конкретно виртуализации непосредственно GPU
Virtual Dedicated Graphics Acceleration (когда видеокарту пробрасывают одной VM) != sharing virtual GPU (когда ресурсы карты дискретно предоставляют разным VM)
под виртуализацией GPU традиционно понимают именно последнее
P.S. по приведенной ссылке, кстати

Parker includes hardware-enabled virtualization that supports up to eight virtual machines

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

тут налицо непонимание разницы между поддержкой виртуализации вычислительной платформой и конкретно виртуализации непосредственно GPU

У кого непонимание? у nvidia? :)

Virtual Dedicated Graphics Acceleration (когда видеокарту пробрасывают одной VM) != sharing virtual GPU (когда ресурсы карты дискретно предоставляют разным VM) под виртуализацией GPU традиционно понимают именно последнее

Ты явно не представляешь, что под капотом, даже если пользоваться твоей VMWare’овской терминологией, то разница настолько призрачна, что её там почти нет, там в современных GPU и DC общих комнонентов раз-два и всё, всё остальное развязано довольно сильно. Есть так же понятие mediator — когда одна и та же GPU пробрасывается всем гестам и хостовый медиатор просто разграничивает права доступа к различным блокам GPU и DC из каждого VM.

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

Ты сам выбрал ARM, как пример, тогда к чему это заявление? ARM — это продукт copy-paste, можно расширять его в сторону сколько позволит кошелёк и пока не столкнёшься с другими ограничениями. До недавнего времени только единицы SoC в ARMv7 поддерживали LPAE расширение и более 4Gb RAM, если 4Gb поровну расшарить между восемью машинами, то будет по 512Mb на машину, такая машина никому не нужна, кроме всяких секьюрных электросчётчиков. Какой ARM может похвастаться наличием более 4 ядер, которые могут _одновременно_ работать? На кой там вообще 8 машин? Основная проблема ARM платформ — это дубовый контроллер памяти, который 4 машины + GPU положат на лопатки. А если подключить 4-6 HD камер, то и одна машина без какой-либо виртуализации не вытянет.

Какой ARM может похвастаться наличием более 4 ядер, которые могут _одновременно_ работать?

:-)
www.phytium.com.cn/...​l?language=1&product_id=7
www.cavium.com/Table.html#thunderx
www.qualcomm.com/...​anometer-server-processor

www.phytium.com.cn/...​l?language=1&product_id=7

The connection has timed out

www.qualcomm.com/...​anometer-server-processor

Это не ARM в классическом понимании вообще. QC использует ARM ISA, но это не ARM core.

www.cavium.com/Table.html#thunderx

Тоже самое. От ARM там только ISA.

Это не ARM

тогда и упомянутый ранее SoC от NVidia — тоже

тогда и упомянутый ранее SoC от NVidia — тоже

Почему?

Тяжело. Ты понимаешь, что у Centriq 2400 не Cortex ядро и что это значит?

Майк, а сколько firmware instances бегает в NVIDIA Tegra 2 при _одновременно_ выполняющихся 2х виртуалках (на разных CPU cores), использующих GPU?

Без понятия. Я понимаю, что пытаться натянуть сову на глобус, эээ ковыряться в семилетнем железе — это особенности национального девелопмента, но не настолько же :)

Сорри, это typo — я имел в виду X2

Касательно Паркера — вопрос с firmware не совсем корректен. У каждого «своя» прошивка, то, на чём ездите вы и мы может кардинально отличаться, и как правило отличается. Например, для Intel APL у нас прошивка не такая, как у всех, с полной поддержкой аппаратной виртуализации. Причём даже в native mode оно работает быстрее :)

Вопрос с firmware вполне корректен и он не о версии или «содержимом» firmware, а о способе виртуализации. Но я думаю что мне ответ понятен :D

Мне кажется, что тебе ничего не понятно. Откуда я могу знать, что ты там у себя запускаешь? Ты запускаешь opensource реализацию для X2? Ты запускаешь nVidia реализацию для X2? Надо полагать, что вопрос про Linux? Какой тип виртуализации ты выбрал? Преемтивный или шэринг GPU с dedicated pipelines? Судя по тому, что ты ждёшь ответ 2, у вас преемтивный шэринг. Но если вы его выбрали (или вам его навязали), то это не означает, что у всех так же. Я в глаза тот линукс не видел, но под QNX из того, что нам дали и что я видел, там вполне честная виртуализация с шэрингом пайплайнов.

LOLWUT? Зачем эти манипулятивне рассуждения про «вам навязали» и «тебе ничего не понятно»? Я спросил о количестве инстансов firmware которые вы одновременно исполняете на GPU, при чём здесь это всё? Раз ты не понимаешь вопроса, то мне ясно что ответ — инстанс у вас один, и ты сам это подтвердил:

под QNX из того, что нам дали и что я видел, там вполне честная виртуализация с шэрингом пайплайнов
Раз ты не понимаешь вопроса,

А это не манипуляция? :) Проблема в том, что я как раз понимаю вопрос, но твоё непонимание ответа говорит, что ты не представлешь, что там под капотом и какие есть варианты.

Я только сейчас наконец-то понял, что ты натягиваешь ваши разработки по SGX десятилетней давности на всё остальное? У меня тогда для тебя плохие новости :)

Чьорд, ты меня разгадал!!!!!!111one

Смысла в этом действии 0.0% :)

RnD буває «бєссмислєнний і бєспощадний»

Смысл появляется только если QNX обслуживает Dom0.

Ця робота робилася дуже давно. Куніксу пропонували впрягтися — вони не захотіли. Може, вважали, що їм віртуалізація не треба. А може вже свій гіпервізор пиляли.
ХЗ (хто зна:).

Куніксу пропонували впрягтися — вони не захотіли.

Xen — GNU GPL version 2. Овчинка не стоит выделки с открытием кода, который Xen будет затрагивать. А затрагивать будет почти всё.

А може вже свій гіпервізор пиляли.

Дык! :)

Я так и не понял зачем виртуализация нужна, экономическое обоснование.
Т.е. есть условно две функции — «свистелки и перделки» (выводить видео на 4к) и контроль и управление (следить за скоростью). Eсть одна функция где нужна высокая надежность (управление) и функция где надежностью можно пренебречь (развлекательная система). Насколько целесообразно ставить один ПК, который должен быть супер надежным и уметь выводить 4к видео (условно), чем поставить один надежный ПК, но который не умеет 4к и один обычный, который умеет 4к видео? Плюс в ситуации с гипервизором, получается что критические функции будут зависеть от софта, что тоже как-то не очень круто.

ПК для развлекательных систем уже стоит в некоторых машинах (как правило премиум класса) — но большая часть мощностей простаивает. Почему бы ее не использовать с пользой (при соблюдении должного уровне надежности) — для отображения кластера (который физически являееться отдельным компьютером в тех же машинах)?

Условная железяка, которая должна рулить и бибикать, должна быть надежной. Это одна цена. Железяка которая может показывать видео, но не быть надежной, это другая цена (меньше). Если вы на «развлекательную» железяку перетаскиваете какие-то критические функции (рулить и бибикать), то падает надежность. Если ставите надежную железяку, которая умеет видео показывать, то возрастает цена, т.к. надежная железяка которая умеет 4к видео, стоит дороже надежной железяки, которая 4к видео не умеет. Ну и плюс по сути вы добавляете еще один софтовый планировщик, который хз как будет себя вести. Одно дело сервера виртуализировать, другое дело тормозную систему.

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

Да, согласен — она конечно должна быть надежная. Но никто не запрещает — если развлекательная железка продемонстрирует необходимый уровень надежности (при прохождении соответствующих тестов, а также доказательстве гарантии стабильности работы критических функции при падении развлекательных функций) исспользовать ее для критических задач (я не говорю о MCU, только о кластере).

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

чушь, у обоих железок не будет никакой аппаратной отказоустойчивости — у них обоих будет относительно низкая надежность (относительно HA-,FT-систем; и дублировать эти системы в автомобиле никто не будет — это не самолет)
тут вопрос к надежности как раз софтовой части — как часто вместо показаний спидометра водитель будет видеть «BSOD»? :-)
и каким образом будет перезагружать машину? :-)
кстати, единственная вычислительная железка тут даже где-то в плюс — будет достаточно единственной кнопки ресет :-)

Одно дело сервера виртуализировать, другое дело тормозную систему

насколько я знаю, полностью электронное управление тормозами сейчас только в F1
и отказ электроники там — не приводит к отказу гидравлики, можно продолжать тормозить традиционным образом :-)
а выход из строя в автомобиле панели приборов, работающей поверх гипервизора, по своим последствиям не будет ничем отличаться от выхода из строя аналоговой приборной панели на другом авто

тут дело в другом — стоимость лицензирования коммерческих версий гипервизоров наверняка легко перекроет экономию на копеечном ARM-железе
так что именно опенсоурсный Xen (читай — халявный) все же неспроста :-)

Компания Mercedes одно время ставила полностью электронное управление тормозной системой. При отказе этелектроники — гидравлика работает в аварийном режиме и крайне неэффективно. На этой почве было очень много жалоб и судебных разбирательств. Сейчас, насколько я знаю, оставили такую систему только на SL.

так что именно опенсоурсный ХХХ (читай — халявный)

Ага ага вы (здесь лично и обобщение) много опыта имеете с «опенсорсный читай халявный» и сколько именно стоит в результате в готовом решении «халявный»?

в решении, на которое один раз потратили деньги и которое может в итоге тиражироваться млн штук?
вот просто теряюсь в догадках от недостатка опыта
смотрю на кучу решений, которые продают именно по подобной бизнес-схеме и вот просто в упор не вижу аналогий
может снизойдете и подскажете с вершин собственного опыта? :-)

Linux подойдёт? Десяток коммерческих дистров взять самый толстый накой себе RHT делает $2B на том что «берёт опенсорсный читай халявный и перепродаёт» и набирает вот таких вот лохов на $2 млрд. странные люди не могут взять и взять халявный опенсорс своими руками.

Linux который в Android подойдёт? Но зачем Android если есть ведь Linux он опенсорсный халявный!?

QNX подойдёт? Ведь есть «опенсорсные халявные» тот же ж Linux за что люди деньги выбрасывают?

VxWorks? У которого кстати есть свой Wind River Linux но зачем есть ведь «опенсорс халявный» кто все эти люди что перепродают за реальные баппки то самое

«опенсорсный читай халявный» и сколько именно стоит в результате в готовом решении

— и кто все эти люди кто это покупает!?

Apache подойдёт? Что-то десятка два разных продуктов все чистый опенсорс все халявные сколько стоит «взять опенсорс халявный и встроить его в готовый продукт» вот скажем железяка какая что-то там делает внутре халявный опенсорсный линукс на нём халявный опенсорсный какой-нибудь Apache Solr через Apache Thrift с мордой на Apache HTTP Server всё халявное опенсорсное сколько стоит?

А сколько стоит сделать фикс? Новую фичу? Просто подождать пока выйдет в самом халявном опенсорсном?

FreeBSD? NetBSD? OpenBSD?

В целом конечно интересно как именно вы себе представляете сам процесс:

в решении, на которое один раз потратили деньги и которое может в итоге тиражироваться млн штук?

Количество людей, которое ставит знак равенства между open source и «халява», зашкаливает :)

Современные приборки не только информацию отображают. Из критического — там хранятся ключи иммо (даже на самых простых VW). А это значит, что без приборки машина просто в кирпич превратится. «Чужую» приборку поставить так просто нельзя, машина не заведется. Если объединять приборку и развлекательную системы, то появляется проблема надежности авто. Получится, что если сломается развлекательная система (все железо имеет вероятность выйти из строя), то машина вообще никуда не двинется, потому что ключи иммо лежат в приборке. А стоимость ремонта для конечного покупателя существенно возрастет, т.к. нужно будет купить дорогостоящую развлекательную систему только для того, чтобы машина поехала.

Более того у того же ж VW развлекательная система таки опциональна даже если предположить что «хоть что-то но есть» то есть то что умеет «стримить 4к и камеру заднего вида» а есть «просто радио» получается таки да:

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

все идет к тому, что и в машинах сразу будут ставить все
а потом можно будет активировать отдельные опции — купив соответствующие лицензионные ключи
у всяких джондиров уже давно подобное

у всяких джондиров уже давно подобное

У Cisco например тоже но тут совсем другая история и сильное желание выдать желаемое за действительное «а зачем так делать? ну зато потом можно будет сделать так!» фишка в том что той же ж Cisco «железно» систему особо отличать нечем там «фичи» именно программные а сама «аппаратная платформа» сильно больших денег не стоит настолько что для большинства реализаций имеются «облачные виртуальные версии» т.е. на самом деле «большой железный ящик» не стоит никаких особых денег в R&D и чисто технически ничего особенного собой не представляет это вообще довольно общая картина для современного «железного решения» но вот с автомобилями это не так и с тракторами впрочем тоже конечно у джондира можно что-то там активировать но на самом деле это только «несущая часть» для всего остального «системного железа» которое покупается отдельно по мере необходимости «навесное оборудование» никто не станет продавать «всё сразу с возможность активации» именно потому что оно денег стоит ровно так же ж никак нельзя «активировать» мерседес Klasse A до S-класса к подавляющему большинству «опций» на всё тот же ж «A-Klasse» это тоже относится нельзя никак «софтварно активировать» опциональный салон опциональную подвеску опциональный свет опциональный цвет кузова и многое другое и даже более того по моему нескромному мнению не станут они продавать «опциональную активацию» на какие-нибудь «плюшки» которые «в железе» и так уже есть в данном пакете это чисто технически невыгодно делать исходя из рынка машина стоит скажем $20K а «плюшка» $500 в MSRP но «плюшка» и так уже есть выгоднее продать на $20K потому что у конкурентов ровно такое же ж но «плюшку» они «дарят в подарок» и всё за те же ж $20K и кстати «азиатские производители второй волны» именно так и поступают именно на этом и делают упор даже безо всяких «активаций» «смотрите у вашего фольксвагена даже кондиционер приходится доплачивать а у нашего аналогичного всё уже в пакете!»

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

Цимес ваших рассуждений таки в том что вы рассуждаете с позиции и опыта Deputy Head of Server and Storage systems Division (к) (тм) а для реального «железячного» рынка это не так.

Нельзя «активировать» iPhone 6 до iPhone 6 Plus нельзя «активировать» гигабитный свич до 10-гигабитного и нет никакого смысла продавать PoE железо по цене «без PoE» «активируя опцию лицензионными ключами». Железо оно другое.

Цимес ваших рассуждений таки в том что вы рассуждаете с позиции и опыта Deputy Head of Server and Storage systems Division (к) (тм) а для реального «железячного» рынка это не так.

Мало того, именно «это не так» является кормом для EPAM и GL, когда автопроизводитель нанимает tier 1 supplier’а для разработки, то для дешевых машин (тут многие их называют лагжери, но это не так, это по Украинским меркам это лагжери, а по северо-американским, например, это шир-потреб) предлагается на выбор два-три SoC, один стоит 8.25, другой 12.99, третий 13.50. Выбирается тот что за 8.25 и спускаются миллионы на разработку той же виртуализации, для которых эти SoC никогда не были задизайнены. Ни о каком стандартном железе и речи нет, например, часто апгрейд «мультимедийной» системы стоит 10К, только потому что меняют пол машины.

Ну если говорить «за условный фольксваген» одним из успешных владельцев лично я являюсь имею место быть то там есть «фишка» когда «апгрейд аудиосистемы» даёт показательный эффект уже в замене «головы» на «такую же ж но более высокого класса в линейке» благо они совместими чисто по разъёмам и по интерфейсам CAN но при этом замена _только_ «головы» #внезапно даёт именно заметный эффект в вопросе качества звука потому как чисто технически элементарную базу «софтовыми лицензиями» ну никак не «заапгрейдишь» при всём при прочих «равных» вроде цветного тачскрина и что там ещё CD-чейнжер что ли?

Это один из наиболее простых и иллюстративных примеров стоят транзисторы и прочая обвязка или просто интегральные усилители пусть за $0.50 в «базовой» модели и пусть даже за $1.00 в «продвинутой» но продать вторые по цене первых «с возможностью активации» никак нельзя хотя целый блок «опциональный» да заменить можно.

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

У Cisco например тоже

конкретно этот пример на 90% мимо
к примеру, не могут они ставят дорогие DSP везде — разорятся :-)

нельзя «активировать» мерседес Klasse A до S-класса

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

нельзя «активировать» гигабитный свич до 10-гигабитного

перестаньте мне перессказывать то, что вы слышали от кого то о коммутаторах :-)

License 10 Gigabit FCIP/Fibre Channel (10G license)
Brocade Extended Fabrics Provides greater than 10 km of switched fabric connectivity at full bandwidth over long distances (depending on the platform)
Ports Ports on Demand licenses required
Почему бы ее не использовать с пользой (при соблюдении должного уровне надежности) — для отображения кластера (который физически являееться отдельным компьютером в тех же машинах)?

Для этого надо реализовать приоритезацию и вытесняющую многозадачность для GPU, а это задача совсем нетривиальная. Ибо кластер имеет больший приоритет.

Я так и не понял зачем виртуализация нужна, экономическое обоснование.

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

dou.ua/...​t-virtualisation/#1155115

Юро, а у мене таки є питання, яке я посоромився спитати на конференції.
А що саме є особливостями застосування віртуалізації в automotive?

Більша частина доповіді — введення в костилі необхідні аби завести систему на залізі без повної апараної підтримці віртуалізації. Решта — опис загальних проблем віртуалізованих систем.

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

Ну то так би і написав, що проблема віртуалізації XEN on ARM в automotive полягає в конфлікті «модно, стільно, молодьожно» і консервативності ринку:
З одного боку tier-1 і вендори хочуть «ВІРТУАЛІЗАЦІЮ». Зокрема, через те, що деякі, відомі вам, люди це активно проштовхували останні 4 роки.
А з іншого боку, в автомотіві дуже довгий TTM для заліза. І систему для машин що будуть випускатися через два роки доводиться будувати на чіпі якому вже 3 роки.

А ще розповів би більше про проблеми сертифікації. Наприклад як в цій презентації www.youtube.com/watch?v=UyW5ul_1ct0 від компанії, яка робить системи на XEN для aerospace/defense.

Не могли бы вы привести пример одной модели автомобиля, который используют подобную виртуализацию? Я прочитал статью и не совсем понял вообще о чем вы пишете. В современном, даже самом бюджетном автомобиле десятка 2 компьютеров (ECU/ECM называется). Каждый такой компьютер самодостаточный, и он отвечает за одну из систем (некоторые можно вообще выкинуть, и машина ездить будет). Взаимодействие между компьютерами может идти посредством CAN, KLine, Lin шин.Сами компьютеры производят совершенно разные производители (Bosch, Siemens, Denso, Delphi, Themic,...), которые ничего не знают о внутренней начинке других. Фактически современный автомобиль — это конструктор, который собрал производитель из разных комплектующих. По аналогии можно взять ноутбук — процессор, память, материнка, матрица — все это разные производители. Задача конечного производителя — увязать это все между собой, чтобы в комплексе все работало.
Что касается обновления блоков, то они обновляются независимо друг от друга при помощи специального дилерского обновления, и проблем с обновлениями вообще нет никаких: techinfo.honda.com/...​bs/web/RJAAI001_J2534.htm
О какой автомобильной платформе с 4Gb вы говорите? Возможно в статье речь именно о развлекательной системе? ECU двигателя суперсовременного автомобиля использует в качестве камня Tricore, там памяти максимум несколько мегабайт, и хватает с головой.

Я думаю, про модель вам ніхто не скаже. По-перше, розробники платформи самі можуть цього не знати. По-друге, є така цікава річ як NDA.

Наприклад, ця конторка www.opensynergy.com/en/homepage, ще в 2014-му казала що у них є в продакшені автомотів системи з віртуалізацією. І навіть на ARMv7 чіпах без апартної підтримки віртуалізації.

Да, но они честно пишут, что занимаются только «in-car cockpit solutions», а не всеми системами авто, которых может быть десятки.

Так ніхто і не каже що поточною задачею віртуалізації є інтеграція ВСІХ систем в один SoC.

Фактически современный автомобиль — это конструктор, который собрал производитель из разных комплектующих.

Обычно определенной моделью автомобиля занимается один поставщик, например Harman, Denso, Delphi, etc.

Дада, прям представляю себе как Harman поставляет компоненты рулевого управления :D

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

И всё же нет. Хорошие примеры из недавних — Toyota, Skoda и Daimler

И всё же да. См. SCM — Supply Chain Management.

Ок, я им передам что они всё делают неправильно

Дада, расскажи Тойоте, как прородителю SCM %)

JFYI: SCM кагбе не диктует наличие только одного Tier 1 сапплаера в проекте. Если не согласен — пруфлинк или слив. Ну и раз уж вспомнили тойоту, то вопрос — кто у них Tier1 по powertrain в новых электрических RAV4? А кто по cluster ecu?

JFYI: SCM кагбе не диктует наличие только одного Tier 1 сапплаера в проекте.

Ты понимаешь значение слова Tier 1?

Если не согласен — пруфлинк или слив.

Щаз. У Тойоты 13 tier 1 suppliers для каждого модельного ряда, машина разбита на 13 поставщиков по каждому из направлений. На этом всё, если у тебя этой информации нет, то ничем помочь не могу, раскрывать я ничего не буду.

Ну и раз уж вспомнили тойоту, то вопрос — кто у них Tier1 по powertrain в новых электрических RAV4?

Tesla — tier 1 из группы P2.

А кто по cluster ecu?

WTF Cluster ECU ? Ты понимаешь разницу между ECU и Instrument Cluster? Как ни странно, один из 13, группа P9, тебе говорят что-то такие названия как Denso, Aisin Seiki? Или ты хочешь сказать, что EPAM tier1 supplier ? %) Вы даже не в Tier 3, как и мы.

Ты понимаешь значение слова Tier 1?

Да

раскрывать я ничего не буду.

Вопрос был про по SCM, а не про Toyota. Что секретного в определениях SCM?

WTF Cluster ECU ? Ты понимаешь разницу между ECU и Instrument Cluster?

Конечно. ECU это общее название электронных контроллеров, Instrument Cluster — один из типов ECU. Словосочетание Cluster ECU приемлемо, более того, некоторые OEMs его официально используют. Ня?

Или ты хочешь сказать, что EPAM tier1 supplier ?

При чём здесь ЕПАМ? Нет, я хочу сказать, что это твоё утверждение неверно:

Обычно определенной моделью автомобиля занимается один поставщик, например Harman, Denso, Delphi, etc.

и ты сам его опровергаешь.

и ты сам его опровергаешь.

Я не опровергаю, я его расширяю. Точка ответственности одна. Это один из Tier 1 поставщиков, который назначает Tier 2. Например тот же Харман может быть и Tier 2/3 как поставщик электроники, так и Tier 1, отвечающий за всю машину. Теперь, как часть Самсунга они выступают как Tier 1 гораздо чаще. Только и всего, что я хотел сказать. И да, Харман одобряет компоненты рулевого управления, если он играет роль Tier 1 при производстве данной модели.

Instrument Cluster — один из типов ECU

Всё чудесатее и чудесатее. ECU — Engine Control Unit, какое он имеет отношение к кластерной панели, кроме коммуникаций для отдачи показаний?

Словосочетание Cluster ECU приемлемо, более того, некоторые OEMs его официально используют. Ня?

Кто использует? Ссылку плиз.

Точка ответственности одна. Это один из Tier 1 поставщиков, который назначает Tier 2.

Вот это как раз и неверно. Вероятно, ты смотришь на машину только как Харман смотрит — кластер там, хедюнит с HMI и свистелками-перделками, ну и пожалуй всё, раз qnx засунуть больше некуда. А тут вдруг на powertrain свой отдельный Tier 1. А ещё иногда Tier 2 suppliers назначает OEM а не Tier 1. И ещё — surprize! — liabilities не заканчиваются на Tier 1, а могут каскадироваться дальше, в т.ч. unlimited liabilities.

Кто использует? Ссылку плиз.

Electrobit использует
www.elektrobit.com/products/ecu
Daimler и Bosch и IEEE используют
grouper.ieee.org/...​/hoganmuller_01a_0712.pdf
ВНЕЗАПНО QNX использует (очевидно, не все сотрудники с этим согласны)
www.qnx.com/...​ies/automotive/index.html

Вероятно, ты смотришь на машину только как Харман смотрит — кластер там, хедюнит с HMI и свистелками-перделками, ну и пожалуй всё, раз qnx засунуть больше некуда.

Если не можешь абстрагироваться от HMI и воспринять слово Харман правильно, ну тогда замени Харман на Denso, огромная корпорация, которая имеет подразделения для каждого узла.

Electrobit использует
www.elektrobit.com/products/ecu

Не нашёл на указанной странице слово cluster вообще.

Daimler и Bosch и IEEE используют
grouper.ieee.org/...​/hoganmuller_01a_0712.pdf

Где? Я опять не нашёл слово cluster в указанной PDF.

ВНЕЗАПНО QNX использует (очевидно, не все сотрудники с этим согласны)
www.qnx.com/...​ies/automotive/index.html

Где? Ты издеваешься? На указанной странице нет такого словосочетания.

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