интерфейс в машине что это
Обзор цифровых интерфейсов современного автомобиля
Отказ от ответственности
Все нижеследующее выражает личное мнение автора, возможно, мне неизвестны какие-либо существенные факты либо знаковые плюсы и минусы какого-то стандарта либо я недооцениваю их потенциал.
Интерфейс LIN (aka ISO17987) — пожалуй самый длинный (если сравнивать по длине линий, а не по весу меди в проводах) пучок в современном авто. Как говорится — модно, доступно, молодёжно. Принцип необходимой достаточности и минимальной цены решения применяемый для некритичных к надёжности и/или безопасности компонент: климатическая установка, кнопки мультируля, стеклоподьемники, замки дверей. Протокол по физике очень похож (берет своё начало) от K-line протокола диагностики, стандартизованного как ISO9141. Во многих микроконтроллерах реализуется на основе аппаратного UART (в том же STM8 имеюттся аппаратные дополнения к UART для поддержки различных реализаций LIN)
Интерфейс CAN (aka ISO11898) — пожалуй, самый известный интерфейс современного автомобиля, во многом благодаря использования как стандарт де-факто для интерфейса диагностики инжекторного двигателя — аля OBD2. Однако, благодаря своим уникальным качествам, нашёл применение в таких ответственных отраслях как промэлектроника, авиация, космонавтика, ЖД и морской транспорт.
FlexRay
Интерфейс FlexRay (aka ISO17458) — пожалуй, можно назвать антиподом LIN в плане стоимости реализации и бесполезности. Поскольку часть обмена по шине осуществляется в режиме TDMA, предьявляются особые требования к точности тактового генератора узлов сети. Сам протокол излишне сложен и надуман (с точки зрения реализации собственного аппаратного контроллера, работающего с FlexRay; однозначно сложнее реализации Ethernet+CAN вместе взятых). На данный момент FlexRay используется на ограниченном количестве моделей автомобилей европейских премиум-брендов (это за >10 лет существования), а дальнейшей экспансией не пахнет. Вероятно, совсем скоро FlexRay загнётся ввиду его замены такими технологиями как CAN FD (сравнимая скорость) и TT-CAN (TDMA работа с шиной).
Интерфейс MOST (не стандартизован ISO) — пожалуй, лишь условно можно назвать автомобильным, поскольку основное назначение — изохронная передача мультимедиаданных (аудио/видео). Не особо понятно почему тот же SPDIF по оптике или коаксиалу не использовать — очередная попытка авто-индустрии придумать «свой» стандарт?
Ethernet AVB
Протокол Ethernet AVB (Audio Video Bridging) — назначение, аналогичное MOST. Протокол описывается целой когортой стандартов IEEE:
Возможно, за счёт многолетних наработок по Ethernet и удешевлению элементной базы, стандарт «взлетит». Предполагаемое использование: передача звука из головного устройства в цифровой усилитель, трансляция картинки на IVI и пассажирские мониторы, подключение обзорных и парк-камер.
Интерфейс SENT (Single Edge Nibble Transmission, aka SAE J2716) — разработанный для автопрома и быстро ставший популярным интерфейс для датчиков. По аналогии с аналоговыми датчиками, используется три провода: земля, питание 5В и данные с датчика.
Характеристики:
Интерфейс PSI5 (Peripheral Sensor Interface) — второй разработанный специально для нужд автопрома интерфейс для коммуникации с датчиками. Это токовый интерфейс, данные в котором передаются модуляцией по питающей линии. Для кодирования бит используется манчестер-кодирование. Выглядит замечательно: прощайте аналоговые трёхпроводные датчики, чувствительные к наводкам!
Кстати, в последних редакциях стандарт предлагает поддержку датчиков системы эйрбэгов.
Вместо послесловия
Запасаюсь попкорном и жду исходов битвы интерфейсов/появления новых кандидатов за место под солнцем. Как показал опыт FlexRay, недостаточно поддержать интерфейс вендорами в кремнии или консорциумами типа ISO/SAE — он, как фрукт, должен вызреть.
HMI как интеллектуальные периферийные устройства
Программное обеспечение HMI можно использовать для создания ценности из быстро увеличивающегося объема промышленных данных. По сведениям корпорации International Data Corp. (IDC), в 2025 г. каждый день будет создаваться 463 Эбайт (1 Эбайт равен 1 квинтиллиону байт) данных [1]. При этом большая часть этих данных будет передана следующими устройствами и технологиями:
Устройства всех перечисленных выше типов продолжают добавлять в свою структуру датчики, а большее число используемых датчиков, естественно, ведет и к большему объему собранных данных. Экспоненциальный рост только одних промышленных систем уже опережает доступную пропускную способность сети. Большая часть данных от машин и процессов остается неиспользованной, но получение доступа к этим сведениям имеет решающее значение для получения ценной бизнес-информации, буквально ее кладезем.
Эффективно использовать данные помогает их обработка с помощью программного обеспечения HMI, развернутого рядом с источником таких данных. Для этого роль HMI должна эволюционировать
Новые роли для программного обеспечения HMI
Программное обеспечение HMI, установленное на периферийных устройствах, должно соответствовать постоянно растущим требованиям к тому, как все типы данных должны быть получены, отсортированы, проанализированы и уточнены. Огромный объем собираемых данных означает, что важную роль в общем плане цифровой трансформации для более разумных операций на операционном уровне должны играть передовая аналитика и машинное обучение.
HMI, как правило, работают с такими источниками данных, как ПЛК и датчики. Традиционно HMI использовались в качестве инструмента визуализации, а иногда и в качестве сборщика данных, просматриваемых на специальной панели управления, мобильном устройстве или в веб-браузере. Современные HMI по-прежнему должны выполнять эти роли, но также собирать данные в реальном времени, хранить их локально для дальнейшего анализа и использовать для поиска закономерностей и выводов, необходимых для составления прогнозов (рис. 1).
Рис. 1. Традиционные HMI технологического и производственного оборудования использовались только для визуализации, но новые продукты, такие как SmartView от компании ADISRA, поддерживают хранение и анализ данных непосредственно на периферии.
Все изображения предоставлено компанией ADISRA
Сейчас HMI развиваются как источник данных для обеспечения машинного обучения в реальном времени. Соответственно, для обучения моделей данные процесса временного ряда должны коррелировать с данными о нарушениях процесса и сопровождающих их событиях. Это позволяет таким моделям определять качество продукта в ходе производства или прогнозировать состояние критически важного оборудования. Модели машинного обучения работают лучше всего, когда для них доступны большие объемы данных с высокой точностью. Прогнозное техническое обслуживание возможно только тогда, когда эти модели заранее обнаруживают отклонения от обычного поведения и указывают на возможный надвигающийся отказ, способный привести к простою оборудования производственной линии или машины.
Четыре способа проверить качество промышленных данных
Чтобы перейти от необработанных данных к аналитическим, человеко-машинный интерфейс должен анализировать входящие сведения от физических активов предприятия и промышленных элементов управления и хранить их в организованном порядке. Решающую роль в закладке основы, необходимой для прогнозного моделирования, играет объединение исторических данных с данными, поступающими в реальном времени.
Модели машинного обучения разрабатываются путем изучения достаточного количества данных, представляющих довольно разнообразный набор, чтобы охватить как можно больше примеров успеха и неудач в соотношении, например, 70/30 (успех/неудача).
Для того чтобы подобрать правильный набор данных с проверенным качеством, требуется время. Также их нужно очистить следующим образом:
При выполнении анализа числовых данных (они необходимы для выявления тенденций) поисковыми методами может быть выброшен большой объем исторических данных, но часто требуется получать и новые текущие данные. При этом пользователи должны убедиться, что обучающий набор не имеет встроенной систематической ошибки. Только после подтверждения достоверности данных можно создавать и применять модели машинного обучения.
Как правильно построить модель машинного обучения
Данные, собранные в реальном времени, поддерживают построение и уточнение модели машинного обучения. Сейчас ведутся споры о том, должно ли после создания модели машинного обучения каждое пограничное устройство иметь возможность изменять модель машинного обучения или такие обновления должны контролировать исключительно люди.
Преимущество возможности изменять модель каждому периферийному устройству состоит в том, что они могут адаптироваться. Однако следствием динамического изменения модели является то, что модели машинного обучения для каждого граничного устройства могут различаться. Последовательно обновляемые модели с большей вероятностью сведут к минимуму проблемы с их поддержкой.
Большинство пользователей начинают процесс разработки модели с контролируемого обучения таким алгоритмам, как линейная регрессия, логистическая регрессия и нейронные сети. Большая часть сегодняшней практической ценности модели — это обучение под контролем человека или как минимум под его наблюдением. Затем уже можно приступить к применению методов глубокого обучения на основе одних лишь данных.
Когда модель машинного обучения находится в приемлемом с точки зрения ее «разумности» состоянии, ее можно развернуть на граничном устройстве, где она сможет работать с данными в реальном времени и искать аномалии. При обнаружении каких-либо аномалий HMI может уведомить пользователя, отправив сигнал тревоги.
Архитектура современного HMI, пограничная аналитика
Роль современного HMI заключается не только в сборе данных, но и в идентификации элементов, событий или наблюдений, не соответствующих ожидаемому шаблону. У такого HMI есть хорошие возможности не только для того, чтобы делать выводы на основе данных и обнаруживать те или иные аномалии, но и для отправки аварийных сигналов через экран, в виде текстовых сообщений или отправления электронных писем оператору о фактических или потенциальных проблемах.
Выполняя обнаружение ближе к источнику данных, человеко-машинный интерфейс позволяет реализовать более раннее оповещение без задержки, свойственной отправке данных в облако. HMI может находить известные шаблоны, способные привести к обнаружению отказа на критически важном элементе оборудования, при этом и логический вывод, и действия на этом уровне обрабатываются локально (рис. 2).
Рис. 2. Расположенные на периферии HMI хорошо подходят для выполнения аналитики и быстрой доставки сообщений и сигналов тревоги пользователям
HMI также могут выполнять и предварительную обработку данных. Благодаря расположению HMI на периферии, его возможности по созданию и генерации выводов в реальном времени он может классифицировать, обнаруживать и сегментировать данные перед их отправкой в облако. Это обеспечивает эффективность восходящей обработки и упрощает организацию сети.
Однако концепция, в рамках которой пограничное устройство должно передавать необработанные, агрегированные или прогнозные данные в облако для дальнейшей аналитики, несколько спорна. Для оптимизации моделей машинного обучения в высокоуровневых или облачных системах потребуются необработанные данные максимальной точности. К сожалению, это может создать для пользователя техническую (аппаратную и сетевую) нагрузку и привести к финансовым затратам.
Необходимость в фильтрации промышленных данных
Основываясь на оценке корпорации IDC, что к 2025 г. ежедневно будет создаваться 463 Эбайт данных, о чем было сказано в начале статьи, пользователи должны принимать осторожные решения о передаче данных, исходя из объема хранилища и пропускной способности сети, необходимой для обновления данных в том месте, где они необходимы для анализа (рис. 3).
Рис. 3. HMI SmartView от компании ADISRA выходит за рамки простой визуализации и помогает OEM-производителям и конечным пользователям управлять передачей данных и выполнять аналитику машинного обучения
Подход на основе необработанных данных предоставляет лучшие базовые данные для моделей машинного обучения. Однако из-за того, что создается огромный объем информации, в этом случае может быть физически сложно передать данные в реальном времени. Когда агрегированные или прогнозные данные в реальном времени предварительно обрабатываются на границе и передаются, объем для передачи ниже. Впрочем, пользователи должны знать, что этот подход может фильтровать или скрывать информацию, позволяя предвзятости проникать в модель машинного обучения.
Другой вариант — отправка агрегированных или прогнозных данных в реальном времени и настройка другого канала для отправки необработанных данных с меньшей скоростью. Потенциальным недостатком является то, что при таком подходе очередь связи может быть быстро заполнена.
Экономические затраты на приобретение пропускной способности сети и устройств хранения должны быть сбалансированы с доступными техническими практическими задачами, такими как определение достаточной стабильности сети. Эти факторы будут влиять на то, где можно развернуть машинное обучение: на границе, в облаке или в обеих точках сразу. Здесь необходим поход на основе функционально-стоимостного анализа.
Расширенная аналитика в HMI и обнаружение аномалий
С помощью современных HMI возможна расширенная аналитика. Большая часть мировых данных —- это потоковые данные и данные временных рядов, аномалии которых предоставляют важную информацию, указывающую на критические ситуации. Существует множество вариантов использования HMI для обнаружения аномалий, включая основу профилактического и прогнозного технического обслуживания, обнаружения неисправностей и мониторинга текущего состояния технологического и производственного оборудования, а также отдельных критически важных машин и механизмов.
Аномалии определяются как момент времени, когда поведение системы становится необычным и сильно отличается от ее поведения в прошлом. Аномалии могут быть пространственными (значение выходит за пределы типичного диапазона) или временными (значение не выходит за пределы типичного диапазона), но последовательность, в которой они возникают, необычна. Метки состояний могут быть связаны с аномалиями и классифицировать их как временные или пространственные. Система аварийной сигнализации также может назначать взвешенные значения для прогнозирования отказа на основе приоритета, важности и частоты.
Любой современный HMI также должен изначально поддерживать механизмы для отправки и получения сообщений с отслеживанием состояния и гарантировать актуальность и достоверность данных удаленного устройства. Связь с отслеживанием состояния может быть обеспечена с помощью таких протоколов, как MQTT (Message Queue Telemetry Transport — легкий сетевой протокол, работающий поверх TCP/IP) и Kafka (распределенный программный брокер сообщений, проект с открытым исходным кодом), а управление состоянием — спецификацией Sparkplug B.
Данные, попавшие в облако, можно агрегировать и объединить с данными из нескольких источников. Ценность здесь заключается в том, что пользователи могут рассматривать несколько операций или весь парк оборудования вместе, независимо от их физического местоположения. Облачную фильтрацию и аналитические модели можно использовать для уточнения данных в рамках глубокого анализа с целью прогнозирования поведения и тенденций, таких как среднее время наработки на отказ (MTBF) или окончание срока службы машин. Затем эту информацию можно развернуть обратно в модели машинного обучения, расположенные на периферии и работающие в HMI, чтобы улучшить работу этих моделей.
Пять требований к современным HMI
Если прогноз корпорации IDC хоть сколько-нибудь близок к правильному, то роль HMI будет возрастать и необходимо соответствующим образом их развить, чтобы вместить огромные объемы данных. Современные HMI могут подключаться к большому количеству машинных данных, чтобы:
Это новая роль HMI, поскольку развертывается все больше датчиков, а зависимость от машин продолжает расти. Критический характер и функции этих машин будут расширяться, и человеко-машинный интерфейс станет мозгом интеллектуальной периферии.
Обзор автомобильных интерфейсов: Как меняется индустрия под влиянием трендов Статьи редакции
Крупные ИТ-компании все ближе подбираются к автомобильной индустрии. Сначала Apple и Google выпустили интерфейсы для синхронизации смартфонов с мультимедийной системой машины. А недавно на улицах Калифорнии был замечен автомобиль, принадлежащий Apple, со странным оборудованием на крыше и колесах.
UX-дизайнер Илья Александров подготовил большой обзор автомобильных интерфейсов и трендов в индустрии.
Концепции автомобилей будущего
Интересно, как изменятся автомобили и их место в нашем обществе в ближайшем будущем. Например, дизайн-компания IDEO представляет свой взгляд на этот вопрос.
Другой пример. Texas Instruments создали ролик о том, каким на их взгляд будет driver experience в обозримом будущем:
Представления разработчиков автомобильной операционной системы QNX об интерфейсах будущего:
Наряду с концептуальными роликами о будущем мы можем наблюдать процесс воплощения технологий в жизнь.
Автоматизация и безопасность
Тестирование всем известных беспилотных автомобилей Google:
Несомненно, за подобными технологиями будущее. Но пока рано говорить о том, что подобные машины полностью заменят водителей. Большинство производителей идут по пути частичной автоматизации. Вот как видит это Mercedes:
Большая часть функций состоит в том, чтобы отобрать у водителя управление, намекая на его несостоятельность:
Экстренное автоматическое торможение, похоже, модный тренд. Меня завораживает этот ролик, с многотонным грузовиком:
Спустимся на уровень GUI. О текущем положении дел в этой сфере дизайнером Teehan+lax написана хорошая статья The State of In-Car UX. Автор сетует на то, что даже покупая автомобиль за большие деньги, вы получаете ущербный по современным меркам интерфейс.
Хотелось бы выделить в этом плане интерфейсы Tesla, которые сделали смелый шаг и предложили нестандартную пока для автомобилестроения парадигму взаимодействия, чем вызвали много шума:
На мой взгляд, немного перегнули палку, избавившись от аппаратных кнопок, но время покажет.
Кстати, часть аппаратных кнопок перенесли на тачпанель не только Tesla. Это решение также можно встретить у Volvo:
Это лишь концепт приборной панели. Обратите внимание на управление климатом снизу панели.
Цифровые приборные панели
Tesla является одним из примеров тренда перехода автомобилей на цифровые (экранные) приборные панели. Они избавились от аналоговых устройств, оставив только дисплей. А на дисплее выводится любая информация. Интерфейс приборной панели становится «живым» и может адаптироваться под конкретный контекст.
Наряду с Tesla многие современные новинки, представляемые на выставках, снабжены подобными дисплеями.
KIA GT Concept 2014
Можете посмотреть подборку приборных панелей, сделанную Денисом Невожаем. Большинство из них — экранные.
К слову, вот цифровые панели из прошлого:
А вот пример современной, сбалансированной между цифровым и аналоговым подходом панели. Панель Volvo спроектирована с любовью к деталям (ролик про ее создание):
А вот как она используется в формировании отличного driver experience (обратите внимание на UI-детали):
NUI, голосовое управление, HUD, Connected car
Управление голосом покрывается как системами CarPlay и Android Auto, так и собственными разработками автопроизводителей. Например, MyFord Touch:
Если вы внимательно смотрели предыдущие ролики с концептами, вы могли заметить в них элементы HUD (head-up display). Это функция вывода информации прямо на стекло. Обычно туда выводится самая важная информация, чтобы не отвлекать водителя от дороги. HUD может поставляться как заводская опция к автомобилю (например, BMW), а может быть установлена самостоятельно.
Тут есть два пути. Первый — приложение для смартфона, не требующее физического устройства, типа Hudway:
Физические устройства с проектором — например, Navdy:
Connected car
Это относительно новый термин, который обозначает подключенный к интернету автомобиль и всё, что из этого следует. По факту, большая часть этой статьи раскрывает этот термин.
Кстати, в России есть сообщество, которое занимается этой темой.
Инфотеймент-системы
Часто помимо приборной панели в автомобилях есть еще одно устройство с экраном и интерфейсами. В нем размещаются функции развлекательного и информационного характера. Каждый производитель традиционно создавал собственную систему, но недавно на сцену вышли новые игроки — сторонние инфотеймент-системы CarPlay и Android Auto (есть и другие системы, но эти появились особо эффектно).
Они устанавливаются в автомобиль и замещают часть функций (звонки, сообщения, музыка, радио, навигация). Система синхронизируется со смартфоном, а управлять ею вы можете с помощью голосовых команд, что очень кстати для автомобильного UX.
Многие производители автомобилей, такие, как Volkswagen и Mercedes, на выставках 2014 года показывали свои модели, которые поддерживают эти системы.
Существуют устройства, которые вы можете купить и встроить в свой автомобиль и которые поддерживают обе надстройки. Например, PARROT RNB 6. Это отдельное устройство с Android OS, но на нем также запускается и Carplay.
Обратите внимание, что в интерфейсе присутствуют собственные приложения (например, звонки) и эти же приложения дублируются в надстройках CarPlay и Android. Также добавляется еще один уровень навигации. Немного сомнительно, но нужно пробовать, чтобы сказать наверняка.
Компания Hyundai также поддерживает оба устройства. В автомобиле есть собственная инфотеймент-система, но при подключении Android или iOS устройства, запускается соответствующая надстройка.
Так как надстройка запускается автоматически и при подключении устройства вы сразу оказываетесь в ней, мешанины меньше, но все равно остаются функциональности, которые есть только в нативном приложении, и придется перемещаться между надстройкой и системой Hyundai.
С точки зрения интеграции CarPlay и нативного интерфейса автомобиля интересный подход у Volvo:
На Medium есть статья, автор которой рассуждает, что в действительности могут дать эти системы автомобильному UX.
Напоследок
NVidia активно продвигает свои «железные» решения в автомобильную промышленность, предоставляя специальные чипсеты для атомобильных компьютеров. Но что более интересно, они также создали инструмент для разработки автомобильных интерфейсов NVidia Drive Studio.
В Automotive есть специальные операционные системы для автомобильной индустрии. QNX — одна из таких систем. Они чаще всего построены на базе Linux или Android, но есть и решения на Windows. Вот пример интерфейса на QNX: