Кейс АТОМ: Как не потерять гибкость при проектировании электромобиля
Привет! Это Дмитрий Гайдук, менеджер в АТОМе по корпоративным и онлайн-сервисам.
Каждое инженерное и программное решение в АТОМе — это отдельный продукт. Но если вырывать эти продукты из контекста, они останутся отдельными разрозненными решениями. Для нас крайне важно изменить само восприятие автомобиля и создать опыт, который задействует все сплетение новых технологий. Проекция дополненной реальности на лобовое стекло, голосовой ассистент, продвинутая система помощи водителю и множество других решений должны соединяться с эргономическими особенностями электромобиля, и только тогда они станут цельной экосистемой.
Как это работает?
Разберем на примере АТОМ-такси. Главная особенность этой модели — отсутствие переднего пассажирского кресла. Очевидное преимущество такого решения: у клиента больше места для ног. Менее очевидное: ничто не перекрывает обзор. Вид на город становится практически панорамным.
АТОМ в версии такси с отсутствующим передним пассажирским креслом
Само по себе отсутствие кресла — еще не тот «новый пользовательский опыт», о котором мы говорим. Но тут в игру вступает софтверная часть АТОМа.
У пассажира АТОМ-такси есть собственный дисплей. Благодаря ему пассажир может получать всю информацию о поездке: маршрут, стоимость, данные водителя и перевозчика, способ оплаты — в общем, стандартный набор функционала из современных приложений. Но операционная система АТОМа позволяет установить и дополнительные приложения. Например, городской гид, который в одно касание создаст персональную экскурсию по достопримечательностям за окном и расскажет о них при помощи голосового помощника.
Для корректной и эффективной работы такому приложению потребуется связь с железной начинкой — датчиком геолокации. К тому же система кибербезопасности проверит на наличие угроз все сигналы, исходящие от гида, и предоставит приложению необходимые разрешения (или заблокирует запросы, которые посчитает сомнительными).
Поднимаемся на уровень выше. Тот самый гид по городу вытекает из другого элемента экосистемы — маркетплейса Atomverse, где сторонние разработчики программного обеспечения могут размещать свои приложения для конечных пользователей. Он, в свою очередь, является частью собственной операционной системы АТОМ, которая работает на железе внутри автомобиля.
То есть, для того чтобы пассажир получил от поездки в такси по-настоящему новый опыт, множество продуктов, заложенных в АТОМ, работают в синергии. Приложение «Гид» в этой логике взаимодействует не только с другим софтом, железом и голосовым помощником, но и с чисто техническим решением об отсутствии переднего кресла, которое увеличивает угол обзора.
А вот для водителя уже другая история.
Есть компании, которые профессионально создают тренинги. И водитель такси, загружая эти тренинги к себе в автомобиль, получает на руле или HUD-дисплее (проекция с дополненной реальностью на лобовое стекло) важную для него информацию:
· как обновились правила дорожного движения;
· как оказывать высокий сервис в такси;
· за что водитель получает хорошие оценки, а за что — плохие;
· как работать с пассажирами.
К тому же дисплей позволяет не только передавать информацию, но и проводить, например, тестирование водителя на знания, которое поможет автоматически принять решение о его допуске на линию. И конечно же мы помним о безопасности: когда мы позволяем приложениям отвлекать водителя (например, в режиме парковки), а когда — категорически нет (во время движения, особенно на высокой скорости).
И таких сценариев эксплуатации цифрового автомобиля — миллионы. Именно поэтому мы говорим, что создаем не просто электромобиль, а электромобиль будущего с очень высоким уровнем автоматизации и продвинутым софтом.
Мы создаем опыт, которого раньше просто не было. Но показали только конечные звенья в цепочке.
А с чего все начинается?
Чтобы достичь амбициозной цели, которую мы ставим перед собой, нужно учесть всю производственную цепочку с точки зрения разработки продуктовой линейки. Необходимо, чтобы абсолютно разные команды из разных индустрий объединились в едином workflow. Причем, workflow у разных команд тоже разный.
Есть инженеры, которые делают автомобиль и работают по достаточно классическому для автомобилестроения рабочему процессу. Они должны за несколько лет до появления машины знать все детали: какова ее архитектура, как связаны отдельные блоки и даже как проходит проводка между этими блоками. Все это нужно, чтобы учесть, сколько пространства заложить в кузове для грамотного проектирования дверей — какой ширины должны быть провода, где располагаются элементы крепления и какими должны быть отверстия при штамповке. Другой пример: расчеты для подачи питания, которое подходит к бортовым системам автомобиля. Их нужно выполнить заранее для грамотного проектирования электронно-компонентной схемы автомобиля.
Любая работа должна быть проделана за два, три и даже четыре года до схода с конвейера.
Добавим еще больше челленджа
Все системы между собой соединены. Например, одна из важнейших частей электромобиля-гаджета — его внутренние «мозги», которые соединены с внешним миром через облачные сервисы и интеграции. Мы не можем допустить, чтобы любой желающий мог через интернет-канал получить доступ к компьютеру, а через него — к двигателю и тормозам. Это прямая угроза кибербезопасности, которая влияет на безопасность физическую. И мы очень внимательно и с полной ответственностью относимся к гипотезам такого рода.
В нашем случае «Лаборатория Касперского» внедрит Security Gateway. Это отдельный компьютер, который объединяет в себе все автомобильные блоки, верифицирует все сигналы, авторизует все запросы извне, чтобы понять: действительно ли это приложение имеет право идти туда дальше, в двигатель? Или это сигнал, который нужно заблокировать?
И здесь начинается самое сложное. Мы выходим в плоскость IT-разработки — когда у тебя нет стопроцентного понимания, что будет через два-три года, и при этом есть достаточно короткие циклы развития ПО.
В зависимости от того, как эти циклы проходят во времени, и в каком объеме мы эти циклы совершаем, появляется понимание, сколько вычислительных мощностей нужно заложить в бортовой компьютер, чтобы все заработало. Как разные системы должны передавать друг другу информацию для ее правильной обработки и максимально быстрой визуализации в интерфейсах автомобиля. И дальше — по цепочке, блок за блоком, провод за проводом, вплоть до сечения кабелей, которые определяют подачу питания для обеспечения вычислительных мощностей.
Инженеры могут сказать: «Если вы сейчас не дадите нам четкое понимание по железу, через два года вы не получите. Мы не сможем спроектировать автомобиль со всеми этими технологическими составными элементами, понять толщину стали, заложить необходимые отверстия под проводку или элементарно найти под все это поставщиков». Или, например: «Вы хотите выводить на дисплей информацию по остаточной жидкости. Вам нужен соответствующий датчик, но так как два года назад его не заложили в проект, мы не подвели к нему провод. И если заложить датчик сейчас, непонятно, как тянуть провод, потому что места под него не осталось. Отверстие сделано так, что провода лежат впритык, и мы не сможем засунуть туда еще один».
Как со стороны продуктовой разработки успеть спроектировать всю эту большую махину и при этом вовремя сдать требования инженерам и разработчикам? На какой срок заключить соглашение с поставщиками проводов, учитывая, что одни принимают заказы за полгода, другие — за полтора, и ни у кого нет идеального готового решения под нас? Что прописывать в этих соглашениях, если им нужно заранее настроить станки, чтобы отгружать десятки тысяч готовых деталей, а требования постоянно меняются? Если не учесть все и сразу, то потом даже простую информацию с обычного датчика получить будет невозможно.
И каков выход?
Синхронизация между отделами произошла не сразу: инженеры пытались делать автомобиль, а айтишники — софт. Жили тоже параллельно: инженеры — в длинных циклах, а айтишники — в коротких спринтах. В итоге это привело к эволюции в оргструктуре компании и пониманию, что нужно мыслить масштабнее, чтобы подобных ошибок не допускать. Пришлось разбить цикл разработки на временные периоды и разобраться, какие функции надо продумывать сильно заранее, а какие можно решить позже и максимально быстро. Так у нас появился продуктовый департамент, который не выделен в классическом IT или automotive-продукте. Он работает с экосистемой в целом, которая включает в себя и железные, и софтверные компоненты, базируясь на эксплуатационной концепции АТОМа.
И вот начинает складываться пазл: нужно уводить часть IT от гибких методологий и вводить в более классическую V-модель. В этой модели гораздо проще учесть условия инженеров и требования по софту, который должен быть не только написан, но и сертифицирован.
В вопросах информационной безопасности мы разделили всю разработку на несколько потоков. Первый — это машина. Второй — ПО, требующее сертификации. Как правило, оно находится «на самом автомобиле». Это операционная система, диагностика, телематика, системы кибер-безопасности, различного рода интеграционные шлюзы.
Третий поток — несертифицированный софт. В основном это программы, написанные сторонними разработчиками, и те приложения, которые создадут тот самый новый пользовательский опыт. Здесь можно использовать agile-подход к разработке, чтобы оперативно тестировать различные гипотезы и включать в работу партнеров. Это необходимо, чтобы расширять зарядную инфраструктуру, облегчать работу автосервисов и расширять взаимодействие с внешними разработчиками или страховыми компаниями.
Все эти пункты не требуют масштабного предварительного планирования и ранней реализации.
А пока проходит разработка самого автомобиля и ПО для АТОМ-2025, мы можем позволить себе пофантазировать на тему того, что не успели сделать сейчас, но должны учесть для будущих автомобилей. Эти идеи мир увидит не в 2025 году, а только в 2027-м или 2030 году. И это будет уже следующая итерация настоящего автомобиля будущего.
