[SimpleSoft 0]

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

 

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

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

 

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

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

 

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

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

 

[AlexandrY 2]

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

 

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

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

 

[SimpleSoft 0]

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

[hdl_student 0]

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

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

Добрый день.

 

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

 

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

 

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

 

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

 

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

[SimpleSoft 0]

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

[syoma 1]

Спасибо за ответ. Можете пояснить про стенды 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 1]

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

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

 

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

[topor_topor 0]

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

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

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

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

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

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

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

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

----

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

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

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

 

----

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

[syoma 1]

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

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

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

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

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

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

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

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

 

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

 

[topor_topor 0]

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

 

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

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

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

 

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

 

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

 

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

[SSerge 3]

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

[topor_topor 0]

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

 

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

 

[SimpleSoft 0]

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

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

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

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

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

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

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

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

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

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

 

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

Edited March 17, 2015 by SimpleSoft

[syoma 1]

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

 

 

[topor_topor 0]

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

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

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

 

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

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

 

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

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

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

 

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

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