Scram для создания аппаратуры. Проект по созданию системы тестирования ADAS или краткая история 8 месяцев нашей жизни
Как он начинался, краткое описание проекта и его ноу-хау
Добрый день, уважаемые коллеги и друзья! Уже больше года я работаю в Армении в компании, которая занимается созданием под ключ сложных, комплексных систем. Взяли меня на роль руководителя проектов, чем собственно я и занимаюсь последние 5 с лишним лет. В данной статье я хотел бы описать краткую историю 8 месяцев из жизни команды разработчиков проекта по созданию системы для тестирования ADAS в YEA Engineering. Это были тяжелые, но интересные 8 месяцев, полные впечатлений и новых открытий, как с технической стороны, так и со стороны управления процессом создания сложных комплексных испытательных стендов. В проекте впервые в компании мы начали применять Scrum, как это у нас получилось и каких результатов мы добились, я постараюсь описать ниже.
Рисунок 1. Oбщий вид системы перед отправкой заказчику
Система, разработанная нашими инженерами представляет собой 2 раздельные коммуникационные стойки HIL (рисунок 1). Первая стойка представляет собой подсистему для тестирования ADAS. Ее структурная схема представлена на рисунке 2.
HIL стойка для тестирования ADAS
Рисунок 2. Подсистема тестирования ADAS
Данная HIL-стойка обеспечивает возможность проверки электронных модулей ADAS в режиме реального времени, посредствам симуляции окружающей среды для воспроизведения и тестирования следующих ситуаций:
Тестирование адаптивного круиз-контроля;
Тестирование системы предупреждения о столкновении;
Тестирование системы экстренного торможения;
Тестирование системы предупреждения о съезде с полосы движения;
Тестирование системы удержания ТС в полосе движения;
Тестирование системы мониторинга слепых зон
Тестирование системы автоматической парковки;
Тестирование системы автоматического перестроения;
Тестирование системы предупреждения при выезде с парковки задним ходом;
Тестирование системы автономного управления ТС.
Для моделирования окружающей среды, автомобиля и перечисленных сценариев было выбрано программное обеспечение Panosim. Положа руку на сердце скажу, что это был не типичный и рискованный выбор. ПО было откровенно сырым, баги, которые мы находили в процессе разработки, устранялись методом выпуска дополнительных скриптов, документация переводилось на английский язык на лету, а коммуникация со службой технической поддержки была ежедневной с использованием всех возможных и невозможных мессенджеров. Но в итоге риск оказался оправдан, так как гарантировать, что столь масштабная система заработала бы при использовании более именитого софта, никто не мог. Техническая поддержка оперативно отрабатывала все наши заявки, вносила необходимые изменения и исправления, помогала подбирать на внутреннем китайском рынке недостающие компоненты и организовывала быструю отправку в Ереван. С точки зрения менеджмента, я получил огромный и положительный опыт от коммуникации с ними.
Наиболее сложным для реализации моментом было заставить работать все в режиме реального времени и с использованием единственного управляющего компьютера. Взгляните еще раз на Рис. 2 и представьте себе невероятно огромный массив данных, который симулировала наша система.
С большими проблемами мы столкнулись при попытке реализации одновременной работы 12 видео потоков. Как оказалось, Panosim работает на движке Unity, у которого есть физические ограничения по использованию видеопотоков — не более 4-ех физически подсоединенных монитора. А у нас их предполагалось использовать 12! О данном ограничении не знали даже коллеги из Китая (я не упомянул ранее, что Panosim — Китайская компания). Решение нашли простое и оригинальное. К выходам видеокарт были подключены видеосплиттеры, которые разбивали 1 видеопоток на 4, таким образом мы смогли для тестирования и работы использовать не 12 мониторов, а 3 (см. Рисунок 3).
Рисунок 3. Как мы вывели 4 видеопотока на 1 монитор
Вторая часть данной стойки выполняла функционал, показанный на Рисунке 4.
Рисунок 4. Дополнительные подсистемы HIL стойки
Наиболее сложной и интересной технологией, заслуживающей отдельного упоминания здесь, является подсистема конвертирования видео сигнала с HDMI TO GiGeVision. Для реализации данной подсистемы мы изначально выбрали готовый продукт, который производят в Англии. Название фирмы не пишу целенаправленно, так как от его использования и общения с ними остались только отрицательные эмоции, если выражаться без использования нецензурных слов. Как итог, мы потеряли уйму времени, нервов, сил и денег. Аппаратура оказалась бракованной и в ближайшее время улетит в туманный Альбион обратно к прародителям. Мы же в свою очередь, совместно с коллегами из Red Feather изготовили свой конвертер на базе технологии от NVidia, который полностью удовлетворил и нас и нашего заказчика.
HIL стойка для тестирования моно и стерео камер
Рисунок 5. Структурная схема стойки
Данная стойка представляет собой комбинацию двух независимых продуктов (Рисунок 5), которые наша компания может поставлять как отдельно друг от друга, так и комбинированно. Более подробно я хотел бы остановиться на описании подсистемы для тестирования стерео камер, как наиболее интересной и сложной.
Подсистема тестирования стерео камер представляет собой компактный бокс, интегрированный в телекоммуникационную стойку. Внутри бокса размещается целевая камера, подлежащая испытаниям. Перед камерой находится механизм (Рисунок 6), включающий зеркала и мониторы. Подсистема обеспечивает проецирование изображения с мониторов на объективы тестируемой камеры с использованием зеркал, реализующих принцип, схожий с принципом работы пентапризмы.
Благодаря центральному размещению тестируемой камеры с двумя объективами и специально спроектированным механизмом зеркал, обеспечивающим возможность тонкой настройки во всех плоскостях, система позволяет эффективно тестировать стереокамеры различных производителей.
Рисунок 6. Механизм подсистемы тестирования стерео камер
Кроме того, держатель камеры в системе также обладает функциональностью тонкой настройки в нескольких плоскостях, обеспечивая точность и гибкость при проведении тестирования. Эта особенность позволяет адаптировать систему для различных моделей стереокамер и обеспечивает высокую степень универсальности в процессе тестирования.
Общая архитектура системы обеспечивает высокую точность и стабильность при тестировании стереокамер, что делает ее эффективным инструментом для оценки производительности и качества различных моделей на рынке.
Ноу хау при внедрении новых процессов проектного управления
Мне кажется я довольно подробно с технической точки зрения описал результат 8 месяцев работы команды из 8 человек. Далее хотел бы описать методы нашей работы, который позволили добиться таких результатов в сжатые сроки и , что самое главное, без особых сюрпризов во время сдачи работы заказчику.
Заранее оговорюсь, что методологию, которую мы использовали, и систему, которую мы выстроили, наша компания внедрила впервые. Речь пойдет о том, как мы адаптировали Scrum для разработки сложных интеллектуальных систем, как выстроили с нуля многие процессы в компании, как взаимодействовали друг с другом и с заказчиком и каких результатов добились.
Как мы разбили проект на фичи и для чего?
В отличие от классического проектного подхода, мы разбили проект на ценности. Фичи или готовые блоки, которые после разработки, можно сразу продемонстрировать заказчику.
Изначально мы спроектировали базовую систему, так называемый скелет проекта, на который по ходу разработки наращивали мясо. Система постепенно становилась все более емкой, приобретала дополнительный функционал и ценность для заказчика. Готовые фичи после тестирования интегрировались в базовую систему, которая с каждым спринтом все больше и больше становилась похожа на конечный продукт.
Демонстрацию ценности заказчику мы проводили по окончании практически каждого спринта. Во время видео звонков, при необходимости, мы сначала показывали рабочий сетап. После чего, как по отдельности, так и одновременно показывали новые разработанные функции. Демонстрация одновременной работы всех виртуальных сенсоров была важной составляющей, так как в техническом задании были жесткие требования к скорости работы.
Именно такой подход, основанный на активном взаимодействии с заказчиком и его вовлечении в работу позволил нам быть уверенными в том, что мы движемся в правильном направлении и, что заказчик от нас ожидает как раз то, что мы и задумали.
Scrum для разработки аппаратуры
В противовес водопадной модели, где есть строгая последовательность этапов при разработке комплексных систем, мы поступили иначе. Мы не стали тратить уйму времени на подробный дизайн всей системы, затем ее проектирование, разработку, интегрирование и лишь потом тестирование, составление диаграмм Ганта, которые по закону Мерфи никогда не сбываются и многое-многое другое. Мы сделали проще и не прогадали. После предварительного поверхностного дизайна, речь идет о разработке структурной схемы системы и разбивке ее на ценности, мы сразу начали процесс программирования. Каждая наша фича проходила все необходимые этапы самостоятельно, а работоспособность системы мы проверяли с каждой интеграцией во избежание сюрпризов в конце.
Из-за высокой неопределенности мы выбрали одномесячные спринты, которые могли бы в себя вместить как разработку софта, так и конструкторскую разработку. Задачи для конструкторов были декомпозированы таким образом, чтобы их можно было бы завершить за месяц при должной сноровке. Конечно не всегда это удавалось, скажу по секрету, чаще не удавалось, но я надеюсь, что навык в нашу команду придет со временем. Демонстрация заказчику в части железа также была значительно реже, однако наиболее интересные системы мы все-таки показывали в 3D-моделях, чтобы оценить их с точки зрения удобства использования. Частые внутренние ревью позволяли конструкторам реализовать свои задумки лучшим способом. В будущем есть идеи подобные ревью сделать чаще, например 1 раз в неделю, что даст меньше шансов напортачить в конце проекта или спроектировать нечто, что идет в разрез с представлением владельца продукта. Еще есть интересная мысль на ревью механических систем звать в том числе и коллег с производства, специалистов по сборке и даже программистов. Ведь интересные идеи с точки зрения эксплуатационных свойств может высказать каждый и не стоит этим пренебрегать.
Что мы получили по итогу закрытия проекта?
Мы сформировали сплоченную команду, которая поддерживает и помогает друг другу;
Достигли прозрачности во взаимодействии с клиентом;
Добились того, что заказчик для нас стал частью команды;
Регулярно демонстрировали результаты нашей работы и получали обратную связь;
Начали более активно проводить ревью внутри команды, но, на мой взгляд, не достаточно часто;
Собрались всеми силами, чтобы завершить проекты вовремя, хотя, к сожалению, это произошло только в последний месяц;
Добились значительной экономии бюджета, как в части закупок, так и в части человеческого ресурса;
Внедрили определенное количество полезных для работы шаблонов, IT-решений и определили ближайшие шаги для улучшения внутренних и внешних процессов;
Сэкономили значительную часть бюджета как с точки зрения закупок, так и с точки зрения задействованного человеческого ресурса (более 30% и там и там).
Как мы можем помочь инженерному сообществу?
Несмотря на то, что YEA Engineering находится в начале пути своего развития, так как развитие это дорога длиною в жизнь, мы хотим делиться нашим опытом с сообществом и имеем огромное желание помочь и вам внедрять лучшие методы организации рабочего процесса.
Мы можем не только решить для вас инженерные задачи, поучаствовать в качестве соисполнителя в ваших проектах, но и попытаться с вами совместно решить задачи совершенно иного характера, лежащие вне зоны физики, математики, электротехники, одним словом инженерной отрасли. Также мы можем внедрить систему проектного управления для вашего бизнеса, провести обучение, создать ряд шаблонов, настроить систему под ваши нужды.
Мы всегда открыты для коммуникации. При желании с нами можно связаться через сайт или LinkedIn:
