Как стать автором
Обновить

Автоматизация аппаратного тестирования Embedded Систем

Время на прочтение3 мин
Количество просмотров4.7K
Продолжим цикл статей об автоматизации тестирования Embedded систем. В этой статье будет рассказано как можно быстро и относительно просто интегрировать возможность управления питанием тестируемого устройства из тестового скрипта а так же получить возможность имитировать нажатия механических кнопок по команде из тестового скрипта.

Итак, что имеем:

  1. Десятки Embedded устройств в которых нужно проводить тестирование новой версии FirmWare (если быть точнее — ежедневная сборка прошивки)
  2. В виду особенностей процедуры загрузки FW может потребоваться необходимость сбросить питание (т.н. режим загрузки прошивки в режиме Power On Capture)
  3. Хотелось бы в некоторые конкретные моменты времени по ходу выполнения тестового скрипта имитировать нажатия на механические кнопки размещенные на отладочной плате Embededed системы

Зачем может быть нужен пункт 3? В моем случае задача следующая — в случае возникновения критического Exception выполнения кода система «встает» в полумертвое состояние из которого она не выйдет пока ей не сбросят питание (еще одна причина для управления питанием). Но самое интересное в том что если в таком режиме нажать специально предназначенную для этого механическую кнопку — в последовательный порт будет выдан т.н. Exception лог — отладочная информация по которой можно будет попробовать понять в каком месте по коду произошло исключение.

Вот именно по этой причине для эффективной автоматизации тестовой установки возникла необходимость иметь возможность ресетить питание устройства и имитировать нажатия механических кнопок на отладочной плате тем самым «спасая» очень важную информацию по Exception от скорой ее утери т.к. тестовый скрипт рано или поздно поняв что ответа от устройства нет попробует ее реанимировать сбросив питание.

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

Анализ схемы отладочной платы показал что кнопка просто замыкает GPIO линию подтянутую к +3.3 В на GND. Значит если «подпаяться» к кнопке и с помощью реле замыкать GPIO линию на землю — то будет то что нужно.

Далее встал вопрос выбора устройства / модуля для управления к которому выдвигались следующие требования:

  • Максимальное число реле (нужно по 2 шт на каждое устройство, а устройств десятки)
  • Доступ по Ethernet
  • Управление URL командами
  • Возможность копировать и масштабировать систему

По традиции остановились на модуле Etherent реле Laurent-128:



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

Схема подключения и связи отладочной платы тестируемого устройства и модуля управления показана на рисунке ниже:



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



Ура! Мехническая часть сделана. Осталось дело за малым — дописать код тестовых процедур так что бы в случае необходимости (загрузка образа прошивки после сброса питания или запись отладки по нажатию кнопки) подать команду на включение / выключение нужного реле.

Синтаксис URL команд управления простой и очевидный. Например, для того чтобы включить реле под номер 4 нужно использовать следующий HTTP адреc:

http://192.168.0.101/cmd.cgi?psw=Laurent&cmd=REL,4,1

А вот и простая функция на Perl которая вызывается из главной тестовой процедуры если нужно «дернуть» реле:

#---------------------------------------------------------------#
# FUNCTION:: click rele
# PARAM1: Laurent IP adress
# PARAM2: RELE ID
# PARAM3: 0 / 1  - what to do with rele
#---------------------------------------------------------------#
sub func_click_pwr_rele {
  my ( $_IN_IP, $_IN_RELE, $_IN_VALUE ) = @_;
  my $url;

  $url = "http://".$_IN_IP."/cmd.cgi?cmd=REL,".$_IN_RELE.",".$_IN_VALUE; 
  
  my $content = get $url;
  if( defined $content ) {
  }
  else {
    func_put_reslog( "ERROR! Can't manage RELE at adress $url", "BAD" );    
  }
}

Отмечу что система работает очень надежно без сбоев и зависаний. Laurent-128 и ранее использовавшиеся Laurent-112 (на 12 реле) отработали по паре лет без сбоев и остановок с учетом ежедневной работы.

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

Теги:
Хабы:
Всего голосов 10: ↑9 и ↓1+8
Комментарии17

Публикации

Истории

Работа

Ближайшие события

2 – 18 декабря
Yandex DataLens Festival 2024
МоскваОнлайн
11 – 13 декабря
Международная конференция по AI/ML «AI Journey»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань