Modular HIL Test Bench або шлях до оптимізації витрат на тестування

Автор: Тарас Попів, Team Lead, Engineering, Consultant, GlobalLogic Ukraine

Більшість із вас хоча б раз були в ситуації, коли для покращення якості проєкту потрібно додатково зробити декілька невеликих завдань, але команда партнера з якихось причини не одразу на це готова. З такою ситуацією зіткнулась і наша команда розробників у GlobalLogic. У цій колонці я хочу поділитись вирішенням, яке створили наші інженери та показати шлях для пошуку рішень, який, сподіваюсь, стане у пригоді ентузіастам та розробникам. 

Чому ми вирішили розробити Modular HIL Test Bench

На проєкті для автоматизованого тестування embedded пристрою використовувалась комплексна програмно-апаратна платформа, розроблена третьою стороною, спеціально для потреб замовника. І наче містила вона все необхідне: високошвидкісний контролер, інтегрована FPGA, модельне програмування (так-так, програмування в графічному редакторі під embedded), різні джерела живлення, можливість використання різноманітних інтерфейсів, велика кількість додаткової периферії. Рішення розроблялось для ручного тестування, але надалі почало застосовуватись і для автоматизованого.

Однак, попри значну кількість переваг, були й деякі недоліки:

• використання різних стеків технологій для програмування пристрою, що тестується, та середовища тестування;
• значна кількість обладнання вимагала початкової ініціалізації, і хоч зі всього переліку використовувалась одна-дві, а то й жодної периферії, проте неправильно проініціалізовані частини(що не використовувались) могли впливати на результати тестів;
• хоча основний процесор і був значно потужнішим за процесор пристрою, що тестувався, та, зважаючи на мову високого рівня, інколи його потужностей було замало навіть для звичайної комунікації, а програмування FPGA для таких цілей – доволі часозатратний процес;
• при використанні великої кількості периферії в системі виникали шуми й “наводки”, які спричиняли помилки в тестуванні;
• оскільки апаратне рішення виготовлялось третьою стороною, виникали труднощі в додатковій кількості обладнання, що збільшувало час тестування основного продукту.

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

Поштовх до змін

Зазвичай, скільки б функцій не було додано до платформи, завжди знайдеться щось, чого не вистачає. От і в нашому випадку не знайшлося функціоналу, який міг би керувати рівнем напруги на контролері, що тестується. Спершу, для розв’язання проблеми була спроба використати наявні на ринку аналоги, та вони не дали бажаного результату. А от розроблений прототип першого модуля успішно вирішив поставлене завдання. 

Його вартість була приблизно вдесятеро меншою за аналоги; процес розробки й виготовлення тривав близько двох тижнів, а головне, це було саме те, чого раніше не вистачало.  Це і стало першим кроком в розробці нашого Modular HIL Test Bench.

Зі збільшенням кількості тестів зростало навантаження на пристрій керування тестовим середовищем, і його ресурс в якийсь момент закінчився.  Замість розділення тестів на частини (для чого необхідно було б не тільки розділити програмну частину, але і створити нові апаратні стенди), було запропоновано використати додатковий контролер, який опрацьовуватиме нові сценарії паралельно з тим, що вже існував. Зважаючи на значну різницю у строках виконання та дешевизну, пропозиція, звісно, «зайшла». Одним із переломних моментів при програмуванні нового контролера було використання того ж програмного стека технологій, що і для основного пристрою. Тепер розробнику не доводилось «перемикатись» зі звичайного «С» на малювання блок схем та оновлення FPGA, що значно прискорило процес розробки та налагодження тестів. А новий контролер, хоч і був слабшим за свого «колегу», та з оптимізованим кодом  виконував значно більшу кількість завдань.  На цьому етапі вдалося використати високошвидкісну комунікацію по SPI інтерфейсу з різними пристроями водночас.

Оскільки нова система працювала стабільно, то  при додаванні чи модифікації чинних тестів, вони додатково переносились на новий контролер. А при необхідності використання нового апаратного функціонала –  розроблявся новий апаратний модуль, керував яким, зрозуміло, новий контролер.

Висновок перший

В наш час вимоги до пристроїв змінюються швидше, ніж час, який потрібен на розробку повного рішення. Припускаю, що після завершення роботи над повним рішенням, воно було б не актуальне. Саме тому, під час нашого процесу розробки ми використали такий підхід коли при появі нової вимоги створюється лише новий максимально простий модуль (а не переробляється вся система), що дозволяє задовольнити дану вимогу з мінімальними фінансовими й часовими витратами.

Переваги рішення 

Приблизно за пів року часу стару систему було поступово замінено на нашу розробку. Кількість апаратних модулів зростала, і створювати зв’язки між ними ставало дедалі важче.  Для розв’язання проблеми модулі та інтерфейси між ними було стандартизовано. Всі вони з’єднувались між собою за допомогою основної плати, на якій були розташовані слоти для розширення. Фактично, саме тоді й з’явився термін «Modular HIL Test Bench», оскільки з основною платою рішення стало модульною системою.

Зважаючи на успіх, нашу систему почали активно використовувати інші команди замовника. Оскільки система модульна – вона підійшла практично всім. Наприклад:

• Потрібна додаткова периферія? Можна просто створити потрібний модуль;
• Щось застаріло, чи не підходить? Модуль можна дуже легко змінити, без впливу на систему загалом;
• Не вистачає ресурсів контролера? Його завжди можна замінити на більш потужний, адже програмна частина теж має модульну структуру і майже не прив’язана до самого MCU.

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

Висновок другий

Основною перевагою цього рішення є модульність. Вона спрощує впровадження системи в проєкт, надає швидку можливість розширення, є простою у використанні (адже використовуються тільки потрібні модулі), забезпечує можливість заміни старого модуля на новий, що дозволяє легко впроваджувати нові технології. Розширення такої системи є максимально швидким та дешевим – час та вартість розробки нового модуля завжди менші, ніж створення комплексного рішення. Завдяки цим перевагам створена система застосовується для тестування нових «embedded» проєктів. У поточному ж проєкті, завдяки впровадженню даного рішення, вартість затрат на тестування зменшилась приблизно у десять разів.