Перейти к содержанию
    

Как тестировать разработанную электронику и встраиваемое ПО?

Здравствуйте!

 

Перед тем как передать разработанные Embedded software & Hardware заказчику или в серийное производство, мы должны его протестировать.

Конечно много зависит и от проекта и от доступных средств тестирования.

 

Как делаем мы:

Пример : Разработка ПО на базе STM32F. Использование Continuous integration вкупе с SVN. Отдел QA сделал Python скрипт для выгрузки и сборки ночью проекта (проект на GCC). Загрузка и запуск на целевой плате через JTAG. Целевая плата подключена к управляемому по USB источнику питания и тестируется с помощью FTDI FT4232H. FT4232H эмулирует I2C, SPI и UART и через скрипты Python оформелны протоколы взаимодействия. Стараемся покрывать, насколько можем, тестами через данные интерфейсы. Также проводим нагрузочное тестирование с помощью данного стенда.

 

Может есть готове комплексы для тестирования? Как вы организовали у себя?

Поделитесь опытом тестирования ваших продуктов.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Разработка ПО на базе STM32F. Использование Continuous integration вкупе с SVN. Отдел QA сделал Python скрипт для выгрузки и сборки ночью проекта (проект на GCC). Загрузка и запуск на целевой плате через JTAG. Целевая плата подключена к управляемому по USB источнику питания и тестируется с помощью FTDI FT4232H. FT4232H эмулирует I2C, SPI и UART и через скрипты Python оформелны протоколы взаимодействия.

 

А у нас на STM32 все пишет один человек. Поэтому ни Continuous integration, ни SVN, ни сборки не нужны.

Поэтому тестирование I2C, SPI и UART не имеет такой актуальности, делается один раз на этапе освоения платформы.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо за ваше мнение! Правильно я понимаю, выходной контроль делается также этим человеком? Это же касается Linux/MQX/WinCE разработок?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может есть готове комплексы для тестирования? Как вы организовали у себя?

Поделитесь опытом тестирования ваших продуктов.

Добрый день.

 

Вопрос очень широкий, тестирование - отдельная область, средства и методы сильно различаются в зависимости от объёма произвоства.

 

Кто-то делает что-то в одни руки, тестирует, соответственно, тоже сам, - а кто-то может себе позволить оснастку с щупами и стенды c PXIe и LabView.

 

Мне кажется, что ваш подход совершенно адекватен мелкой-средней серии.

 

У нас серийность очень мелкая, поэтому обходимся имитаторами интерфейсов средней степени интеграции (как правило, контролируется наличие связи, протокол и обработка ошибок, в общую систему имитаторы, как правило, не завязаны), методика тестирования описана в отдельном документе. Принимает тест ОТК и военные.

 

Делать что-то крупнее в нашем случае совершенно нерентабельно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо за ответ. Можете пояснить про стенды PXIe? Как их используют для тестирования?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо за ответ. Можете пояснить про стенды PXIe? Как их используют для тестирования?

В серийном производстве достаточно надежной электроники - например блоков управления впрыском для двигателей, различных плат для ездящего и летающего, используются стенды с контроллерами. Стенды могут быть сделаны для чего угодно - от тестирования законченного устройства через стандартные разъемы, до индивидуальных плат с игольчатыми щупами.

PXI - это всего лишь шина, на которой построены контроллеры от National Instruments. Можно взять и другие, но у NI в придачу есть среда Labview, которая как раз специально заточена под создание различных тестов и GUI.

Внизу фотки такого стенда - сверху игольчатый адаптер - внизу PXI контроллер и прочая периферия.

post-25368-1426543274_thumb.jpgpost-25368-1426543298_thumb.jpg

post-25368-1426543351_thumb.jpg

 

Вопрос в том - сколько вы готовы вложить в такой стенд? Для простенького устройства цены начинаются от 20k€ и выше.

 

Стандартный тестовый стенд - их тех, что я видел, обычно состоит из стандартного набора компонентов:

- колодки для подключения теструемого устройства или механического адаптера для установки платы.

- Break Out Panel - обычно такая большая панель, на которую выведены все сигналы устройства и которые там-же можно вручную закоротить или разомкнуь - помогает при поиске неисправноестей

- Signal Conditioning Modules - преобразователи цифровых и логических уровней в/из стандартизированные +-10В, 0...5В. Обычно с гальванической развязкой для моделирования I/O сигналов для тестируемого устройства и проверки его реакции.

- Программируемый блок питания с возможностью изоляции питания.

- PXI или другого промышленного контроллера, который собственно и проводит тестирование. Он также загружает прошивки через jtag и проверяет коммуникационные интерфейсы - Ethernet USB и т.д.

- промышленный компьютер с виндой и LAbView, который собственно управляет всем этим делом и показывает результаты.

 

Все это дело обычно ставится в стойку или шкаф, чтобы было транспортабельно в пределах производства. Для того, чтобы стенд не выкидывлся после того, как вышло новое изделие, он обычно делается модульно - т.е. все эти преобразователи - одноканальные на DIN-рейку, контроллер - тоже модульный - количество I/O может меняться в широких пределах. Ну и софт - с возможностью быстрой перенастройки стенда на другие тесты в предельно сжатые сроки и без специальных знаний - LAbView. Сейчас вроде как и Матлаб начинают применять.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопрос в другом - все эти стенды обычно используются на выходном контроле при серийном производстве. Для контроля при сдаче разработки в производство я особого смысла в таком стенде не вижу.

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

 

Но так как это единичные случаи - смысла в специализированном стенде я не вижу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Интересная тема. Хотелось-бы уточнить и расширить

1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?

2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?

Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.

Нужно доказать что интерфейсы соответствуют стандарту и т.п.

3) Как доказать что RTL также соответствует ТЗ?

Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?

4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?

----

Ну а после всего этого можно поговорить и о том какой и где "тестер" нужен.

На одном этапе нужно доказать что всё спроектировано безглюков и работает, а на другом - что спаянная плата соответствует Э3...

То как описано у автора топика похоже на последнее....

 

----

Есть и универсальное решение PXI Platform ... если денег не жалко....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?

2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?

Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.

Нужно доказать что интерфейсы соответствуют стандарту и т.п.

3) Как доказать что RTL также соответствует ТЗ?

Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?

4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?

По моему, эти вопросы выходят за рамки данной темы. Тут речь идет о тестовых стендах, а не о качестве и выборе тестов.

 

Но, конечно, вопрос а какой стенд нужен ТС, остается открытым.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По моему, эти вопросы выходят за рамки данной темы. Тут речь идет о тестовых стендах, а не о качестве и выборе тестов.

 

Но, конечно, вопрос а какой стенд нужен ТС, остается открытым.

Стенд нужен тот, который указан в ПМ, которые пишутся на основании ТУ, в объёме ПИ\КИ\ПСИ, а ТУ обязанно опираться на ГОСТ, ОСТ на данный тип оборудования.....

Таким образом "стенд" это может быть и барокамера в которую всуното изделие со штатной программой и работающее как в приложении....

 

Ежели речь о проверке что всё запаяно правильно и есть контакт (на этапе ПСИ), то тогда можно изготовить тест платку со всеми интерфейсами (иногда можно отделаться нульмодемными заглушками) и зашить в устройство отладочную програмку которая дёргает все провода внутри устройства и выдаёт\принимает посылки на\от внешние порты. Это-же можно добится, внедрив JTAG в плату.

 

Если это попытка подтвердить правильность проектирования на этапе ПИ - то такой платки совершенно недостаточно, нужно может закупить сертифицированный специальный тестр PCI интерфейса и при этом доказать качество програмного кода по специальной методике (тут аппаратно ничего и не надо).

 

так-что вопрос "нужен тестовый стенд" - неоднозначный.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

"Тестирование может показать наличие ошибок, но не может доказать их отсутствие" © Э. Дейкстра.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

"Тестирование может показать наличие ошибок, но не может доказать их отсутствие" © Э. Дейкстра.

 

А что Э. Дейкстра знал о test coverage?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

syoma, Torpeda, спасибо за ответы.

SSerge, это точно. Но знание какие ошибки в образце уже верный путь к их исправлению. Зачастую задача сделать не идеальный продукт, а продукт который соответствует требованиям.

1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?

2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?

Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.

Нужно доказать что интерфейсы соответствуют стандарту и т.п.

3) Как доказать что RTL также соответствует ТЗ?

Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?

4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?

Вопросы очень(!) правильные, более того, по отношению заказчика к тестированию, также можно понять его уровень и возможности.

 

syoma, если говорить о сериных продуктах, пробовали ли вы прошивать платы с помощью иголок, Test Points (куда выведен JTAG) и прогонять JTAG Boundary Scan тесты? Если да, то можете поделиться информацией какое оборудование использовали и впечатления от использования?

Изменено пользователем SimpleSoft

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

syoma, если говорить о сериных продуктах, пробовали ли вы прошивать платы с помощью иголок, Test Points (куда выведен JTAG) и прогонять JTAG Boundary Scan тесты? Если да, то можете поделиться информацией какое оборудование использовали и впечатления от использования?

По поводу JTAG сказать ничего не могу - у нас все лилось по USB и Boundary Scan не было. Поэтому мы все проверяли только функциональными тестами.

Могу более по Signal Conditioning или модульным контроллерам.

 

 

1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?

2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?

Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.

Нужно доказать что интерфейсы соответствуют стандарту и т.п.

3) Как доказать что RTL также соответствует ТЗ?

Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?

4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?

Ну если предположить, что система управления требованиями у Вас настроена и работает - что сам по себе уже значительное улучшение культуры разработки, то самое интересное по вашим вопросам(кроме п.4), что я в последний раз видел на Embedded World - это система тестирования требований. Т.е. засовываете в нее свои требования и она каким-то образом прогоняет все варианты, чтобы можно было увидеть, где есть пробелы. Причем это еще до начала проектирования устройства. Я так толком и не понял, как это работает, но вроде работает.

По п.4. - климатика и ЕМС в принципе самое простое - есть стандарты - им надо соответствовать. Если уверены в своем изделии, то лучше всего тесты делать на конечном этапе, чтобы протестировать изделие в как можно близком к серийному варианте, чтобы не было вопросов при сертификации. Если не уверены - делаете промежуточные тесты до конца разработки. Мы, например, в первый раз микросекундные импульсы тестировали задолго до конца разработки на I/O и входе блока питания, чтобы не переделывать второй раз.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По п.4. - климатика и ЕМС в принципе самое простое - есть стандарты - им надо соответствовать. Если уверены в своем изделии, то лучше всего тесты делать на конечном этапе, чтобы протестировать изделие в как можно близком к серийному варианте, чтобы не было вопросов при сертификации. Если не уверены - делаете промежуточные тесты до конца разработки. Мы, например, в первый раз микросекундные импульсы тестировали задолго до конца разработки на I/O и входе блока питания, чтобы не переделывать второй раз.

Надо следовать стандартам предявляющим требования к изделию и особенно стандартам, указывающим методику проведения испытаний (а-то есть любители вентилятор в термокамере включать...)

Не забываем про метрологию и правильный подбор приборов по класу точности (чтобы не тратится всюду и везде на дорогущие "цезиевые" эталоны) и совместимости по входу.

 

Что касается когда делать тесты...

Количество и объём тестов во время разработки - соответственно фантазии и квалификации разработчика :)

 

Дальше следуем стандарту постановки изделий на производство.

"тесты делать на конечном этапе, чтобы протестировать изделие в как можно близком к серийному варианте, чтобы не было вопросов при сертификации." - называется квалификационные испытания (КИ). Это всё что указано в стандартах предявляющим требования к изделию (в т.ч и пожаробезопасность, и транспортопригодность по дорогах класса "Г", и даже те, что розрушают изделие, и что USB это USB и т.д. и .т.п)

На конечном этапе производства проводятся ПСИ, которые гораздо короче КИ и только гарантируют что изготовлено всё как в чертежах.

 

JTAG - это помощь в промежуточных точках контроля техпроцеса (к КИ, ПСИ это не относится), а именно прозвонки после пайки. Ну и других технологических операциях - прошивка флешки напр.

К сожалению встраивается только в большие микросхемы (микропроцессоры, FPGA). Поэтому и подходит больше для модулей где есть только такие микросхемы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...