Как тестировать разработанную электронику и встраиваемое ПО?, Делимся опытом Опции

[SimpleSoft]

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

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

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

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

[AlexandrY]

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

А у нас на STM32 все пишет один человек. Поэтому ни Continuous integration, ни SVN, ни сборки не нужны.
Поэтому тестирование I2C, SPI и UART не имеет такой актуальности, делается один раз на этапе освоения платформы.

[SimpleSoft]

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

[hdl_student]

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

Добрый день.

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

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

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

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

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

[SimpleSoft]

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

[syoma]

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

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



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

Стандартный тестовый стенд - их тех, что я видел, обычно состоит из стандартного набора компонентов:
- колодки для подключения теструемого устройства или механического адаптера для установки платы.
- Break Out Panel - обычно такая большая панель, на которую выведены все сигналы устройства и которые там-же можно вручную закоротить или разомкнуь - помогает при поиске неисправноестей
- Signal Conditioning Modules - преобразователи цифровых и логических уровней в/из стандартизированные +-10В, 0...5В. Обычно с гальванической развязкой для моделирования I/O сигналов для тестируемого устройства и проверки его реакции.
- Программируемый блок питания с возможностью изоляции питания.
- PXI или другого промышленного контроллера, который собственно и проводит тестирование. Он также загружает прошивки через jtag и проверяет коммуникационные интерфейсы - Ethernet USB и т.д.
- промышленный компьютер с виндой и LAbView, который собственно управляет всем этим делом и показывает результаты.

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

[syoma]

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

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

[Torpeda]

Интересная тема. Хотелось-бы уточнить и расширить
1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
3) Как доказать что RTL также соответствует ТЗ?
Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?
----
Ну а после всего этого можно поговорить и о том какой и где "тестер" нужен.
На одном этапе нужно доказать что всё спроектировано безглюков и работает, а на другом - что спаянная плата соответствует Э3...
То как описано у автора топика похоже на последнее....

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

[syoma]

1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
3) Как доказать что RTL также соответствует ТЗ?
Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?

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

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

[Torpeda]

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

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

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

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

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

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

[SSerge]

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

[Torpeda]

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

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

[SimpleSoft]

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

1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
3) Как доказать что RTL также соответствует ТЗ?
Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?

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

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

Сообщение отредактировал SimpleSoft - Mar 17 2015, 20:23

[syoma]

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 и входе блока питания, чтобы не переделывать второй раз.

[Torpeda]

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

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

Что касается когда делать тесты...
Количество и объём тестов во время разработки - соответственно фантазии и квалификации разработчика

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

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